|
|
Posted by boots on 07/29/05 22:54
The way I see it, how you organize is going to be largely dependant on
whether you choose to associate requests with actions or you rather
associate requests with views.
If you associate requests with an action then you will tend to build-up
and push data into your templates. This often (in my experience) can
lead to some breaking of the abstraction as you are sometimes forced to
specify presentation linkages from your action controller. In other
words, you end up pushing not just application data, but also document
structure and formatting directives.
If you associate requests with a view then you will tend towards
pulling data from your templates and will likely deploy many custom
plugins that manage application logic. This too can lead to leakage in
the abstraction since your templates become controllers and thereby can
make unpredicted associations between application components.
My first attempts at Smarty were more of the second kind but mostly I
have tended towards the first sort where actions are tied to requests.
The action would then develop a rendering object which was just a
hierarchy of rendering components that were eventually passed to a
master processing template. Each object would specify the rendering
requirements, such as css files, templates, etc and provide data to
complete the work.
I am moving away from that because there is ever more creep of
presentation concerns into my business logic API. I am not quite back
to associating requests with views (though I am getting closer) and am
presently in a hybrid quagmire. The main barrier to associating views
with requests is that sub-templates typically can not add processing
information to the <head> of the rendered document meaning that an
outside process needs to co-ordinate that -- and this is the main
reason I had been tending towards associating requests with actions. I
recently submitted a new Addon at the forum and posted at the Wiki that
I am hoping will help me streamline the process. The main thing with
this approach is that the plugins you provide must be able to
introspect the application to some degree (or at least query
application objects) in order to determine state and appropriateness.
In many cases, I am favouring having the plugins accept a rendering
template as a parameter so as to not push the templating directly into
the plugin code and thereby maintaining the abstraction.
I should note that there are pros and cons to both types of
associations and I am not trying to suggest that one is better than the
other. On-the-other-hand, I do try to stick with approaches that are
flexible and easy to manage and develop. I have found that associating
requests with actions leads to more developer involvement and tends to
give less flexibility to designers and trusted template users.
--- Vicente Werner <vwerner@gmail.com> wrote:
> My setup lacks any directory structure since the templates are stored
> in a db, and as such templates are categorized:
>
> MASTER: they define the basic layout of the site load the css, etc...
> BASE: They're the actual nodes with content, calls to components
> EXTRA: Small regions that being static themselves are repeated all
> over the site, they're invoked by master or base templates
> COMPONENT: They're the templates that actually belong to a "gui"
> component of the site (forms, workflows, etc..)
>
> Both component & extra are outside the hierachy and are called where
> needed
>
> Every template type can contain any other type and form a hierachy,
> of it's own.
>
>
> On 7/29/05, Monte Ohrt <monte@ohrt.com> wrote:
> > OK while we're sharing, here is my setup (or rather some of its
> basics)
> >
> > We have an environment with multiple sites (clients) that can have
> > multiple "themes", or look-and-feel to their site that they can
> swap
> > with the change of one variable. Then there are "modules" such as
> news,
> > calendar, classifieds, etc. The top-level client/site directory
> > structure is as follows (these are not under doc root!):
> >
> > /templates/
> > /theme1/
> > init.tpl
> > header.tpl
> > footer.tpl
> > layout.tpl
> > /mod1/
> > location_top.tpl
> > location_left.tpl
> > location_main_content.tpl
> > /images/
> > /theme1/
> > masthead.gif
> > /mod1/
> > module.gif
> > /css/
> > /theme/
> > /mod1/
> > /configs/
> > /theme/
> > lang_en.conf
> > lang_de.conf
> > /mod1/
> >
> >
> > templates, images, css and config files are broken down to global,
> > theme-specific and module-specific directories. We keep
> > language-specific config files under each theme.
> >
> > I have one "controller" PHP script that acts as the controller (see
> the
> > guestbook example app for complete example)
> >
> > This script will do something like this (crude example):
> >
> > index.php:
> >
> > $smarty = new Smarty;
> >
> > // set from config file
> > $smarty->theme = 'bluestuff';
> >
> > // set by running module
> > $smarty->mod = 'calendar';
> >
> > // do some stuff to figure out what page we are displaying
> > // do whatever necessary tpl var assignments here
> >
> > $smarty->assign('page','main_menu');
> > $smarty->display("init.tpl");
> >
> >
> > The init.tpl acts as the template controller, it basically loads
> the
> > global init.conf then loads the theme-specific init.tpl:
> >
> > init.tpl:
> >
> > {config_load file="init.conf"}
> > {include file="$theme/init.tpl"}
> >
> > $theme/init.tpl then loads theme-specific stuff, then decides if
> we're
> > loading the main layout or something else:
> >
> > {config_load file="$theme/init.conf"}
> > {config_load file="$theme/lang_$lang.conf}
> > {if $page eq "showimage"}
> > {include file="$theme/showimage.tpl"}
> > {elseif $page eq "printable"}
> > {include file="$theme/printable.tpl"}
> > {else}
> > {include file="$theme/layout.tpl"}
> > {/if}
> >
> > The $theme is set in the constructor for the current "theme". There
> is
> > an init.conf that contains global config vars, and also an
> init.conf for
> > each theme for theme-specific settings. layout.tpl contains the
> > framework for each page, it minimally contains location cells that
> can
> > be controlled per module. Notice that the layout can be skipped,
> such as
> > an "image-only" or "printable" page. Here is a watered-down example
> of a
> > layout.tpl:
> >
> > layout.tpl:
> >
> > {include file="$theme/header.tpl"}
> > <table>
> > <tr>
> > <td colspan="2">{include
> file="$theme/$mod/location_top.tpl"}</td>
> > </tr>
> > <tr>
> > <td>{include file="$theme/$mod/location_left.tpl"}</td>
> > <td>{include file="$theme/$mod/location_main_content.tpl"}</td>
> > </tr>
> > </table>
> > {include file="$theme/location_footer.tpl"}
> >
> > That is a very crude example, but basically you put your HTML/CSS
> here
> > to make the theme look how you want. Each module can control what
> shows
> > up in the location templates. location tpls are useful for banners,
> > module navigation, etc. The location_main_content.tpl is what shows
> up
> > in the center of the page, it minimally includes module-specific
> content
> > and templates for whatever page we are on, such as:
> >
> > {include file="$theme/$mod/$page.tpl"}
> >
> > Then you have a template for each module page in that directory.
> >
> > That should be enough to put everyone to sleep :)
> >
> > Monte
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Navigation:
[Reply to this message]
|