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]
