EOLing old page models and macros (was Re: Atlas: Refactoring ContextLoader out of existence)

[Dave Johnson <sn...@gmail.com>]

On 6/9/06, Allen Gilliland <al...@sun.com> wrote:
> comments inline ...
>
> Dave Johnson wrote:
> > Comments inline...
> My plan would simply be to deprecate all of the old stuff in the context
> rather than try and EOL it.  We'd do that in these general steps ...
>
> 1. Round up the current context loading stuff and any objects it uses
> and group it all together somewhere that is identified as legacy context
> loading crud.  This includes the current page model, page helper, etc.
> Something like ui.rendering.legacy or ui.rendering.old.
>
> 2. Leave the legacy context loading process in place on the page
> servlet, which is the only place that users have templates that use that
> stuff.  Remove it from everywhere else, feed, search, etc.
>
> 3. Define completely new page models to be used moving forward.  These
> models will be totally self contained and designed how we want things to
> work moving foward.
>
> 4. Rewrite our existing velocity templates and themes to use only the
> new page models and any other supporting objects that we want to
> continue supporting for the long term.  To lighten this burden I suggest
> that we make 3.0 the point at which we EOL all the old themes and pick
> just a couple new ones to refactor and ship with Roller for 3.0 and beyond.
>
> 5. Optionally we can define some kind of mechanism to turn off the old
> context loading stuff.  Probably the best way to do this is to begin
> tracking what version of Roller the person began their installation
> with.  So starting with new installations 3.0 we could have the old
> context loading stuff disabled by default.  This is still a possible
> problem though, if someone gets their hands on old templates/themes in a
> 3.0+ install they will no longer work, so we need to tread carefully here.
>
> So the basic approach is to isolate all of the old stuff and consider it
> deprecated.  Then change our existing stuff to only use the new code
> which we want to use moving forward.
>
> The other fairly cool thing about this is that we would only document
> the new models and objects that we really want to support as we create
> them.  We don't want to tell people about the old stuff and give them a
> chance to start doing things the wrong way.


OK. I'm game.

I'm going to propose entirely new page models and macros. It doesn't
make sense to muck around with ContextLoader anymore if we're going
to EOL the old page models and macros in the 3.0 timeframe.

- Dave

Re: EOLing old page models and macros (was Re: Atlas: Refactoring ContextLoader out of existence)

[Allen Gilliland <al...@sun.com>]

Dave Johnson wrote:
> On 6/9/06, Allen Gilliland <al...@sun.com> wrote:
>> comments inline ...
>>
>> Dave Johnson wrote:
>> > Comments inline...
>> My plan would simply be to deprecate all of the old stuff in the context
>> rather than try and EOL it.  We'd do that in these general steps ...
>>
>> 1. Round up the current context loading stuff and any objects it uses
>> and group it all together somewhere that is identified as legacy context
>> loading crud.  This includes the current page model, page helper, etc.
>> Something like ui.rendering.legacy or ui.rendering.old.
>>
>> 2. Leave the legacy context loading process in place on the page
>> servlet, which is the only place that users have templates that use that
>> stuff.  Remove it from everywhere else, feed, search, etc.
>>
>> 3. Define completely new page models to be used moving forward.  These
>> models will be totally self contained and designed how we want things to
>> work moving foward.
>>
>> 4. Rewrite our existing velocity templates and themes to use only the
>> new page models and any other supporting objects that we want to
>> continue supporting for the long term.  To lighten this burden I suggest
>> that we make 3.0 the point at which we EOL all the old themes and pick
>> just a couple new ones to refactor and ship with Roller for 3.0 and 
>> beyond.
>>
>> 5. Optionally we can define some kind of mechanism to turn off the old
>> context loading stuff.  Probably the best way to do this is to begin
>> tracking what version of Roller the person began their installation
>> with.  So starting with new installations 3.0 we could have the old
>> context loading stuff disabled by default.  This is still a possible
>> problem though, if someone gets their hands on old templates/themes in a
>> 3.0+ install they will no longer work, so we need to tread carefully 
>> here.
>>
>> So the basic approach is to isolate all of the old stuff and consider it
>> deprecated.  Then change our existing stuff to only use the new code
>> which we want to use moving forward.
>>
>> The other fairly cool thing about this is that we would only document
>> the new models and objects that we really want to support as we create
>> them.  We don't want to tell people about the old stuff and give them a
>> chance to start doing things the wrong way.
> 
> 
> OK. I'm game.
> 
> I'm going to propose entirely new page models and macros. It doesn't
> make sense to muck around with ContextLoader anymore if we're going
> to EOL the old page models and macros in the 3.0 timeframe.

coolio.

as you write up these proposals a couple things that would be nice to 
see are 1) what servlets will apply the given models and 2) a very 
general breakdown of what objects are needed to initialize each model 
and what general methods/objects the model will provide access to.

nothing too complete, just enough so we have a rough idea of how the 
models are meant to be used.

-- Allen


> 
> - Dave