Glad you agree, if you have time to get to this before me, please start
implementing it. One other thing, I have already found the need to create
another "template"Layout module. This one does not use the ecs document
class and writes directly to the response PrintWriter. My reasons for
wanting it are frames related, but it can also be useful for those who just
want to use wm #parse directive for page layout. I still have a lot of
details to work out, but the reason I bring it up is that it will be
necessary to pick the Layout module for a layout template in a similar
manner to the way a Screen module is assigned to a screen template. Since
naming is related between the two I think it will be possible to use the
same module names which are being placed into 00packages00, which is a name
I don't like, but wanted give notice of possible generalization in the event
you start implementing TemplateInfo.
----- Original Message -----
From: dave bryson <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Wednesday, May 03, 2000 11:06 AM
Subject: Re: WM/FM templates
> On Wed, 03 May 2000, you wrote:
> > A few things I think should be done as far as integration with
templates:
> >
> > If the preferred way of using Turbine is to make use of templates, we
need
> > to make some default classes to handle the fact that the homepage, error
> > screen, etc. may be specified by template as opposed to a Screen. An
> > initial thought is to add a property such as default.presentation.method
> > with values "template" or "screen" (or maybe "javaobject"). This
property
> > will then control the way properties such as homepage, error.screen,
> > login.screen, etc. are interpreted. It will then be necessary to create
some
> > default implementations as templates.
> > Another property that would be good to add is default.template.extension
> > with values "html", "fm", "wm", or any other extension the developer
wishes.
>
> Yes This would be good because I've been thinking of converging
> the two module Pages into one for both FM and WM. Futher with these
> properties I think we could move back to having one DefaultPage so the
> users would not have to switch.
>
> Also, I'd like to move the "parseScreenpath/Layout" code into one
> central place..
>
> >TemplateInfo class in the util package.
> Yes.
>
>
> >
> > And one more thing I would like to see added is an SQLAction module that
> > takes a text file (we could standardize, so that an parameter like
> > action=selectusers.sql would automatically use the SQLAction) as input.
The
> > sql statement(s) could be parsed and submitted via Village or using
straight
> > JDBC. The results of the action should be automatically placed within
the
> > Context object for use within the template. (It may be that this is
moving
> > something that belongs in a Screen, so let's discuss proper placement.)
> > What I am essentially after is a way for people who are unfamilar with
Java
> > to use Turbine (of course someone in the organization is going to need
to be
> > fluent in Java,) to present db data. One might say this is going to
> > encourage application development in a non-OO manner, but some simple
> > applications and more to the point information management systems can be
> > built using something like the above and not suffer from the design.
>
> After all the MVC talk, this sounds like where getting away from it.
> But the reality is that I think it would useful and needed by some.
>
> What about providing access to DBconnection via the context? Then you
> could use Village right in the template
>
> --
> dave
> [EMAIL PROTECTED]
> ----------------------
> < your inspirational quote here >
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
