On 7/5/01 9:26 PM, "John McNally" <[EMAIL PROTECTED]> wrote:
> Jon Stevens wrote:
> <snip />
>>
>>> I just don't like
>>> the %2C's littering my URLs.
>>
>> Pick another character then. It is easy to write your own class in Turbine
>> to do so. Much easier than writing it yourself from scratch.
>>
>
> Or write another implementation of the TemplateService. I think there
> are many people who would prefer a service that allows them to match
> layout template, java classes, actual screen template based on a key.
> The lookup is then done based on an xml file (or some other format). I
> do not know what is gained by this approach, but I hear some people
> prefer it. And you are then free to write the key in any format.
My thoughts are that any type of arbitrary output will be possible
in 2.2 by creating a display pipeline. The default will be the
classic pipeline which is how people are familiar working with
turbine: page/layout/nav/screen. But I'm hoping that any arbitrary
aggregation of modules will be possible.
There is a hint of this within the new ModuleLoader and how Turbine.java
is using it to add types of modules. The template service is currently
bound to page/layout/nav/screen nomenclature and will probably still
have this trait on the next big check in. I think this will make direct
binary output easier and allow models that are present in projects
like jetspeed where there are really a bunch of screens on a page
at the same time, or portlets as they call them. They have bent turbine
in order to do this and I'm hoping that arbitrary aggregation from
a set of renderers will be easy.
I have some Struts/Turbine thoughts too if anyone is interested. Much
of what is very useful in Turbine is code that consists in the services
and Torque. I know I keep blathering on about how I will separate soon,
but it will happen sooner rather than later. When this happens there
is absolutely no reason that the services, many of which are webapp
specific, will be of great use in Struts. The services are now unbound
from Turbine.
For example, some useful services that could be used in Struts are
the database service, the upload service. These will be entirely
useful in struts and I'm hoping to make some example struts applications
so that hopefully our groups can work on Fulcrum (the name of the services
framework) together. Fulcrum will have a separate build system and
will be package separately from Turbine so that it can be easily
incorporated into any java application, webapp or not.
Torque will also be useful, it will be separate and there is no reason
that Torque can't be used in tandem with Struts. I even think to some
extent that the TDK could be altered slightly to generated example
struts applications. I think the severing of the services and torque
will be great for both groups. Struts is widely used and it would
be fabulous if the struts community found the services and torque
useful and helped work on them to make them better. I have tried
to decouple some heavy ties to turbine and I think I have succeeded.
I definitely had a view toward trying to persuade struts users/developers
to dig into the services and torque.
But I am also hoping that 2.2 will be greatly simplified and easier
to use, yet be a lot more powerful than it was previous. I know I sound
like a marketing department, and I am in a way, but 2.2 I believe will
be a great improvement. That's my not so humble opinion :-)
>
> I have suggested this before, though and even restructured the current
> template service to allow this to be done by subclassing the current
> implementation, and no one has done it. So maybe I am wrong and there
> aren't that many people who prefer "mapping spec" approach.
>
> john mcnally
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
