At 13:30 01/30/01, Raphaël Luta wrote:
>ingo schuster wrote:
> >
> > At 07:48 01/30/01, David Sean Taylor wrote:
> > >After several reads, it is taking me some time to understand this, but
> I get
> > >the overall concept, but Im a little fuzzy in the details.
> > >
> > >I've also been looking at the new Turbine Pull Service.
> > >You can find it in the cvs head at org.apache.turbine.services.pull
> > >Also see: http://java.apache.org/turbine/pullmodel.html
> > >It appears a little thin, but I like the concept very much.
> > >
> > >The pull model, in my interpretation, is a way to bring an object model
> > >directly into template pages.
> > >This will allow designers to access, or pull, objects and their attributes
> > >directly in a template page, whether it be Velocity, WebMacro, JSP,...
> >
> > What I'm worrying about is that the work of web designers get mixed up with
> > those of progammers: A web designer shouldn't really have to care about
> > programming and everything that the toolbox provides needs to be hidden
> > behind a *very* simple interface (like JspTags). It has to be made sure
> > that no business logic find it's way into the templates. All business logic
> > should be executed by actions that put their results in the template
> > context, the templates should only care about reading and rendering these
> > results and about the "page flow". I.e. there should be only a very spartan
> > "API" with e.g. methods to lookup/generate/rewrite appropriate links, but
> > it shouldn't provide "a way back" into the portal (e.g. no methods to
> > access the user object or other "mighty" objects).
> >
>
>That's because you don't use a proper template engine ;P
>The syntax of Velocity/Webmacro is very simple on purpose to prevent
>designers from using complex constructs and embedding logic into their
>pages. They mainly let the designer access "business" objects which
>encapsulate/mask all the business logic.
>The "pull" methodology adds the advantage over the push methodology
>that the "business logic" programmer does not need to know in which
>page the objects will be used (this may change each time a site is
>redesigned even if then logic is unchanged). As such, it provides
>a better separation of contexts between the page designer work and
>the business logic programmer.
Well, if Webmacro/Velocity doesn't allow dirty things - ok, that's good.
I'm just looking from the Jsp perspective and at least for Jsp templating,
we should try to hold the toolbox as simple as possible. For example: I
don't think a template should have the ability to access _business
objects_, not even for querying them. Instead the business logic (the
actions) should provide the processing results trough a "helper object" (a
JavaBean). _Utility_ code (like a link builder) should of course be
accessible for the templates.
ingo.
>--
>Raphaël Luta - [EMAIL PROTECTED]
>Vivendi Universal Networks - Services Manager / Paris
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/[email protected]/>
>List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
