|
|
Posted by Jochem Maas on 07/30/05 13:04
boots wrote:
> 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.
>
....
>
> 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
[what's below could get very boring very quickly for some people ;-)]
I solved this problem with a subclass of Smarty (a php5 class I
call SmartyPage). this class takes care of diplaying a header (the doc HEAD
+ opening TAG) the content (the actual viewable page) and a footer.
my class has a pageDisplay() method which wraps 3 calls to Smarty::display/fetch()
the content template is fetched first then the header is displayed, there after
the fetched output from the content tpl is output and lastly the footer is
displayed.
My subclass class has 3 methods for injecting 'stuff' into the HEAD:
SmartyPage::addJavascript( <url to js file> );
SmartyPage::addStyleSheet( <url to css file>, <css media relevance e.g. 'screen' or 'print'> );
SmartyPage::addJavascriptGlobalVar( <js var name>, <js var value> );
I then have a few custom plugins that allow 'content' templates (and any
subtemplates) to add stuff to the HEAD (which is actually always diplayed
by way of the header tpl after the content tpl is fetched) e.g:
{addjavascript file="/js/core/selectoptions.js"}
In addition I have developed a class PageBase which is used to define
default DOCTYPE, js files, css files, global js vars, header tpl, footer tpl - the PageBase
class can be subclassed and the definitions in the superclass can be
either augmented or overridden as required - the upshot is that I can create a
small set of PageBase subclasses (very simple classes without methods) that specify how
different kinds of pages (e.g. stdpages, popup pages, order transaction pages, etc)
for a project to diplay a page with a given content template I call my subclass like so:
$tpl->pageDisplay('defaultbikeparts.tpl');
or
$tpl->pageDisplay('defaultbikeparts.tpl', 'SimpleIntranetPageBase');
I started using Smarty in Nov2003 - and I have been developing my class ever since then...
and it's being successfully used in various projects including a site which
won the people's vote for 'best webshop 2005' in Holland (not really as 'big' as it sounds
- but I'm proud to say I built it, not the graphic design btw!, and that Smarty plays no
small part!)
---
If any of the core Smarty guys is interested in looking
at my code I would be prepared to spend a bit of time rolling a zip file
that contains all the relevant files needed to make it work (it forms part
of my custom framework so there quite a few dependencies, some of which are
only relevant to me, which I would have to work thru/check)... php5 is a
requirement.
If others want to look, I might consider it too - but really if you do want to
look your php(5) skills will have to be pretty good and you will have to want to
take the time - which is why I offer it to the core/dev guys - I know they have the
skill and that they do research (otherwise they would never have been able to write
such a consistent, solid piece of code!) - regardless if my offer is taken up I will
place the files somewhere everyone who is interested can grab it.
any takers? (I have no config/setup documentation but the code itself
is quite heavily documented) I'll say up front that I am very willing to answer any
questions that may arise from people who investigate what I have done.
(if it's not obvious... I would love to give back a little code to the community
that I have received so much from!)
rgds,
Jochem.
> 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]
|