基于级别/层的框架的策略

发布于 2024-08-13 02:34:32 字数 2218 浏览 2 评论 0原文

目前我有一个基于遗留的非 MVC php 框架,我需要更新它以支持升级/功能系统。

我想要两种模式,一种是正常模式(当前模式),另一种是基于级别的模式,我可以在其中控制包含哪些功能 - 低、中、高级别。

例如,低层不支持谷歌地图,而中层和高层则支持。各层之间的布局也有所不同,因此除了当前的模板之外,我还必须为每个层提供一个模板主文件。

并且关卡模式中的高级和当前模式之间有一个区别,即高级中包含某些东西,但当前模式(非基于级别)具有无限的功能。

目前系统结构的布局如下:

templates/
    default.php

includes/
    branding.php
    css.php
    js.php
    map.php ( google map )

如果您访问 index.phpcontact.php 它只会执行 require_once APP_PATH 。 '模板/default.php'

我知道这不是最理想的 环境类型,因为它不是 MVC 基于但这就是我所坚持的 自动提款机。

templates/default.php 看起来像这样:

<!doctype html>
<html>
<head>
    <?php include APP_PATH . 'includes/branding.php';
</head>
<body>
    <?php
    switch ( filename ) {
        case 'map':
        include APP_PATH . 'includes/map.php';
    }
    ?>

<?php
include APP_PATH . 'includes/google.php';
?>
</body>
</html>

这是一个相当老式的模板文件类型。

为了支持调平系统,我怀疑我必须将我的框架结构更改为类似的东西。

templates/
    level-0.php
    level-1.php
    level-2.php
    level-3.php

includes/
    branding.php
    css.php
    js.php

现在在我的配置文件中,我必须定义一些常量,例如..

define('LEVEL', 1);
define('TEMPLATE_FILE', APP_PATH . 'templates/level-' . LEVEL . '.php');

default.php 变成 level-0.php 并且对于基于层的模板,它们分别是 1、2、3。

因此,现在当我访问 index.phpcontact-us.php 等页面时,我将包含 TEMPLATE_FILE 常量:

require_once TEMPLATE_FILE

-这是理想的吗?有什么缺点吗?

如果我采用这种方法,我将拥有 4 个单独的模板文件,这很好。例如,最低层不会包含map,而最高层则会包含。

我关心的另一个问题是子分支,可以在包含文件中进行分支吗?一个例子是最低层不会有图标。 favicon 元素位于 includes/css.php 中,因此我必须在该文件中进行分支:

includes/css.php:

<link rel="stylesheet" type="text/css" href="main.css">
<?php if ( LEVEL !== 1 ) { ?>
<link rel="shortcut icon" href="favicon.ico">
<?php } ?>

- 这可能会有点混乱,但它节省了我的时间到处复制 css.php 并且必须更新它的 4 个实例。这是理想的吗?

对于这个问题,我深表歉意,感谢任何建议。

Currently I have a legacy based non-MVC php framework which I need to update to support a leveling/feature system.

I want to have two modes, a normal mode ( the current mode ) and a level based mode where I control what features are included - low, medium, high tiers.

For example, the low tier will not support google maps, while the medium and high tiers will. The layout varies between the tiers as well, so I have to have a template master file for each tier in addition to my current template.

And there is a difference between the high tier in level mode and the current mode, in that there are certain things included in the high tier, but there are unlimited features in the current mode ( non-level based ).

Currently the system structure is laid out as such:

templates/
    default.php

includes/
    branding.php
    css.php
    js.php
    map.php ( google map )

If you visit index.php or contact.php it just does a require_once APP_PATH . 'templates/default.php'

I know that isn't the most ideal
type of environment since it isn't MVC
based but that's what I'm stuck with
ATM.

The templates/default.php looks something like:

<!doctype html>
<html>
<head>
    <?php include APP_PATH . 'includes/branding.php';
</head>
<body>
    <?php
    switch ( filename ) {
        case 'map':
        include APP_PATH . 'includes/map.php';
    }
    ?>

<?php
include APP_PATH . 'includes/google.php';
?>
</body>
</html>

So a fairly oldschool type of template file.

In order to support the leveling system I suspect I'll have to alter my framework structure to something like..

templates/
    level-0.php
    level-1.php
    level-2.php
    level-3.php

includes/
    branding.php
    css.php
    js.php

Now in my configuration file I'll have to define some constants, such as..

define('LEVEL', 1);
define('TEMPLATE_FILE', APP_PATH . 'templates/level-' . LEVEL . '.php');

default.php becomes level-0.php and for the tier based templates, they are 1, 2, 3 respectively.

So now when I visit a page such as index.php or contact-us.php I would include the TEMPLATE_FILE constant:

require_once TEMPLATE_FILE

- Is this ideal? Are there any drawbacks?

If I go with this method I'll have 4 separate template files and that's fine. So for example the lowest tier won't include the map include while the highest tier will.

Another issue I'm concerned with is sub-branching, is it ok to branch out within the include files? An example is that the lowest tier won't have a favicon. The favicon element is in includes/css.php, so I'll have to branch within that file:

includes/css.php:

<link rel="stylesheet" type="text/css" href="main.css">
<?php if ( LEVEL !== 1 ) { ?>
<link rel="shortcut icon" href="favicon.ico">
<?php } ?>

- This might get a bit messy, but it saves me from duplicating css.php everywhere and having to update 4 instances of it. Is this ideal?

I apologize for the loaded question, appreciate any advice.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

三岁铭 2024-08-20 02:34:32

这对我来说看起来很混乱,我想知道为什么你要以这种“平衡”的方式进行。因为对我来说,它看起来像是 4 级显示,1 级是最少的,4 级是最多的。

如果你问用什么框架来替代你现有的框架,任何一个都可以(有很多 PHP 框架,搜索一下,我最喜欢的是 codeigniter.com)

另外以 CSS 为例,我很困惑为什么你会这样做费心做一些像网站图标这样微不足道的事情(但我当然可以看到你的每个显示级别选择性 CSS 的示例)。

但我只会有一个 CSS 文件(或分为 4 组:general、lev1、2 等;),然后包含并合并到一个 CSS 中。

但是当你击中要害时,它会变得混乱,我会分开内容,或者更好的是,坐下来重新编写整个项目,看看问题出在哪里,你似乎已经确定了自己尝试先写出项目,然后在对项目范围感到满意后对其进行编程。

否则,我不建议在没有明确的行动方针的情况下开始编程。

希望有帮助

This just looks messy to me, and I wonder why you are going about in this 'leveling' fashion. Because to me it looks like 4 levels of display, 1 being the least, and 4 being the most.

If you are asking what framework to substitute for the one you have, any will work (there are many PHP ones, do a search, my fav is codeigniter.com)

Also looking at the CSS as an example, I am confused why you would bother doing something as insignificant as the favicon (but I can certainly see your example of selective CSS per display level).

But I would just have once CSS file (or broken down into 4 sets: general, lev1,2 etc;) then include and merge into one CSS.

But as you hit the nail on the head, its going toget messy, I would just seperate the content, or better yet, sit down and re-write this whole project, see where the problems are going to be, you seemed to have identified a few yourself, try to write out the project first, then program it once you are happy with the project scope.

Otherwise I would not suggest starting to program without a clear course of action.

Hope that helps

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文