On 7/4/01 12:28 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:
> on 7/4/01 9:15 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
>
>> This will lend to ease of use because the org.apache.turbine.* package
>> will be the first place to look and it will start allowing us define
>> how people use our code in a more strict fashion so we can move forward
>> without fear of breaking things all over the place.
>>
>> Thoughts?
>
> Works for me. I'm a bit worried about the amount of code breakage as a
> result of the re-packaging, but I'm sure we are all used to that at this
> point.
When 2.2 is done, and the adapter code is fully operational we will
have a bridge for as much as possible and I think the impact won't
be as severe as thought. There are definitely going to be some things
that can't be cleanly adapted and I think the clean refactoring and
the development of a stricter API takes precedence.
> My only other concern is that org.apache.turbine will become crowded and
> hard to manage.
Looking at standard usage patterns I don't think there is that much
that needs to be placed in the top level package. People will be making
screens, actions and using contexts along with standard templating. I'm
sure this will grow slightly but I think even 15-20 classes in the top
level package is about as high as it should get.
> When that happens, people will want to put stuff into sub
> packages. Therefore effectively creating what we already have today and a
> move will be moot. What do you think about that?
I think it is our job to limit this growth in favour of long term
stability. Again, I don't think this class list will grow wildly and
I don't think it should. In the past there haven't been a lot of additions
to the core portions of turbine. There has been a lot of services code,
but this isn't going to part of turbine. I think Turbine is more of
a display pipeline, and even if we embrace every templating engine
now available with the abstract templating engine this would require
no addition classes in the top level package.
If we analyze how turbine is used, and how it might grow I think
we would see some standard patterns: people making screens and actions,
sometimes making new session validators, possibly ACLs and a few other
things. If we look at the current limitations we can probably make things
more general so that a lot more doesn't have to be subclassed. This is
not to say that I want to limit Turbine's functionality or have it be less
flexible, but I think we can satisfy everyone's needs (and then some)
without the class hierarchy growing uncontrollably. I think we can limit
if not stop the growth with some care now.
I see turbine being able to deal with all localization and mediatype issues
and provide a flexible display pipeline (beyond what it is currently capable
of in our standard page/layout/nav/screen system), yet I don't see the
number of classes required to accomplish this being that large. At least
not in the top level package.
I have tried to think about projects that have found turbine limiting
and am trying to remove those limitations and I think with a good hard
look at the 2.2 alphas and betas we will arrive at something that will
accommodate almost everything and still be very lean and tight.
> -jon
>
>
> ---------------------------------------------------------------------
> 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]
