Deprecating components

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecating components

Richard Lewis-Shell
Hi,

I am thinking it would be useful to add support to Tapestry for
deprecating components, so that we can provide a clear migration path
for changing components.  It can imagine it would be useful to be able
to deprecate an entire component and/or individual component parameters,
and have Tapestry display a warning when such components/parameters are
constructed.  It would probably be desirable to be able to disable those
warning messages, perhaps via a system property.  Off the top of my
head, it might look like this:

Foo.jwc:
<component-specification ...>
    <deprecated message="Use the simpler Bar component instead of Foo"/>

    <parameter name="something">
        <deprecated message="Use somethingElse parameter"/>

...

e.g. there is a thread on the -user list at the moment about merging
Insert and InsertText.  If deemed a good idea, it would be nice to
deprecate the InsertText component, leaving it in Tapestry 4, and
removing it from the next significant release.

Any thoughts?

Richard

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating components

Jamie Orchard-Hays
I like this idea. It would definitely be useful.

Jamie


On May 14, 2005, at 5:15 AM, Richard Lewis-Shell wrote:

> Hi,
>
> I am thinking it would be useful to add support to Tapestry for
> deprecating components, so that we can provide a clear migration path
> for changing components.  It can imagine it would be useful to be able
> to deprecate an entire component and/or individual component
> parameters, and have Tapestry display a warning when such
> components/parameters are constructed.  It would probably be desirable
> to be able to disable those warning messages, perhaps via a system
> property.  Off the top of my head, it might look like this:
>
> Foo.jwc:
> <component-specification ...>
>    <deprecated message="Use the simpler Bar component instead of Foo"/>
>
>    <parameter name="something">
>        <deprecated message="Use somethingElse parameter"/>
>
> ...
>
> e.g. there is a thread on the -user list at the moment about merging
> Insert and InsertText.  If deemed a good idea, it would be nice to
> deprecate the InsertText component, leaving it in Tapestry 4, and
> removing it from the next significant release.
>
> Any thoughts?
>
> Richard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating components

Howard Lewis Ship
I've been thinking about this too; including a deprecation service that
would log the deprecation warnings ... but just once, so you don't get
flooded.

On 5/14/05, Jamie Orchard-Hays <[hidden email]> wrote:

>
> I like this idea. It would definitely be useful.
>
> Jamie
>
>
> On May 14, 2005, at 5:15 AM, Richard Lewis-Shell wrote:
>
> > Hi,
> >
> > I am thinking it would be useful to add support to Tapestry for
> > deprecating components, so that we can provide a clear migration path
> > for changing components. It can imagine it would be useful to be able
> > to deprecate an entire component and/or individual component
> > parameters, and have Tapestry display a warning when such
> > components/parameters are constructed. It would probably be desirable
> > to be able to disable those warning messages, perhaps via a system
> > property. Off the top of my head, it might look like this:
> >
> > Foo.jwc:
> > <component-specification ...>
> > <deprecated message="Use the simpler Bar component instead of Foo"/>
> >
> > <parameter name="something">
> > <deprecated message="Use somethingElse parameter"/>
> >
> > ...
> >
> > e.g. there is a thread on the -user list at the moment about merging
> > Insert and InsertText. If deemed a good idea, it would be nice to
> > deprecate the InsertText component, leaving it in Tapestry 4, and
> > removing it from the next significant release.
> >
> > Any thoughts?
> >
> > Richard
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating components

Howard Lewis Ship
I've also been thinking about having a list of "aliases" for parameters, for
when we want to give them better names.

On 5/15/05, Howard Lewis Ship <[hidden email]> wrote:

>
> I've been thinking about this too; including a deprecation service that
> would log the deprecation warnings ... but just once, so you don't get
> flooded.
>
> On 5/14/05, Jamie Orchard-Hays <[hidden email]> wrote:
> >
> > I like this idea. It would definitely be useful.
> >
> > Jamie
> >
> >
> > On May 14, 2005, at 5:15 AM, Richard Lewis-Shell wrote:
> >
> > > Hi,
> > >
> > > I am thinking it would be useful to add support to Tapestry for
> > > deprecating components, so that we can provide a clear migration path
> > > for changing components. It can imagine it would be useful to be able
> > > to deprecate an entire component and/or individual component
> > > parameters, and have Tapestry display a warning when such
> > > components/parameters are constructed. It would probably be desirable
> > > to be able to disable those warning messages, perhaps via a system
> > > property. Off the top of my head, it might look like this:
> > >
> > > Foo.jwc:
> > > <component-specification ...>
> > > <deprecated message="Use the simpler Bar component instead of Foo"/>
> > >
> > > <parameter name="something">
> > > <deprecated message="Use somethingElse parameter"/>
> > >
> > > ...
> > >
> > > e.g. there is a thread on the -user list at the moment about merging
> > > Insert and InsertText. If deemed a good idea, it would be nice to
> > > deprecate the InsertText component, leaving it in Tapestry 4, and
> > > removing it from the next significant release.
> > >
> > > Any thoughts?
> > >
> > > Richard
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com 




--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating components

Mind Bridge
> I've been thinking about this too; including a deprecation service that
> would log the deprecation warnings ... but just once, so you don't get
> flooded.

> I've also been thinking about having a list of "aliases" for parameters,
for
> when we want to give them better names.

+1 to both. Would be very helpful and would definitely make some changes
easier.




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating components

Robert Zeigler-2
In reply to this post by Howard Lewis Ship
The ability to deprecate parameter names in favor of "better" names is
fine, and doing this would probably require an "alias" ability... I
think that the two should be used in tandem, though. Having the ability
to alias a parameter name could get messy, otherwise.

Robert

Howard Lewis Ship wrote:

> I've also been thinking about having a list of "aliases" for parameters, for
> when we want to give them better names.
>
> On 5/15/05, Howard Lewis Ship <[hidden email]> wrote:
>
>>I've been thinking about this too; including a deprecation service that
>>would log the deprecation warnings ... but just once, so you don't get
>>flooded.
>>
>>On 5/14/05, Jamie Orchard-Hays <[hidden email]> wrote:
>>
>>>I like this idea. It would definitely be useful.
>>>
>>>Jamie
>>>
>>>
>>>On May 14, 2005, at 5:15 AM, Richard Lewis-Shell wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I am thinking it would be useful to add support to Tapestry for
>>>>deprecating components, so that we can provide a clear migration path
>>>>for changing components. It can imagine it would be useful to be able
>>>>to deprecate an entire component and/or individual component
>>>>parameters, and have Tapestry display a warning when such
>>>>components/parameters are constructed. It would probably be desirable
>>>>to be able to disable those warning messages, perhaps via a system
>>>>property. Off the top of my head, it might look like this:
>>>>
>>>>Foo.jwc:
>>>><component-specification ...>
>>>><deprecated message="Use the simpler Bar component instead of Foo"/>
>>>>
>>>><parameter name="something">
>>>><deprecated message="Use somethingElse parameter"/>
>>>>
>>>>...
>>>>
>>>>e.g. there is a thread on the -user list at the moment about merging
>>>>Insert and InsertText. If deemed a good idea, it would be nice to
>>>>deprecate the InsertText component, leaving it in Tapestry 4, and
>>>>removing it from the next significant release.
>>>>
>>>>Any thoughts?
>>>>
>>>>Richard
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>--
>>Howard M. Lewis Ship
>>Independent J2EE / Open-Source Java Consultant
>>Creator, Jakarta Tapestry
>>Creator, Jakarta HiveMind
>>
>>Professional Tapestry training, mentoring, support
>>and project work. http://howardlewisship.com 
>
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating components

Richard Lewis-Shell
In reply to this post by Howard Lewis Ship
parameter aliases would be implicitly deprecated right?

Howard Lewis Ship wrote:

> I've also been thinking about having a list of "aliases" for parameters, for
> when we want to give them better names.
>
> On 5/15/05, Howard Lewis Ship <[hidden email]> wrote:
>
>>I've been thinking about this too; including a deprecation service that
>>would log the deprecation warnings ... but just once, so you don't get
>>flooded.
>>
>>On 5/14/05, Jamie Orchard-Hays <[hidden email]> wrote:
>>
>>>I like this idea. It would definitely be useful.
>>>
>>>Jamie
>>>
>>>
>>>On May 14, 2005, at 5:15 AM, Richard Lewis-Shell wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I am thinking it would be useful to add support to Tapestry for
>>>>deprecating components, so that we can provide a clear migration path
>>>>for changing components. It can imagine it would be useful to be able
>>>>to deprecate an entire component and/or individual component
>>>>parameters, and have Tapestry display a warning when such
>>>>components/parameters are constructed. It would probably be desirable
>>>>to be able to disable those warning messages, perhaps via a system
>>>>property. Off the top of my head, it might look like this:
>>>>
>>>>Foo.jwc:
>>>><component-specification ...>
>>>><deprecated message="Use the simpler Bar component instead of Foo"/>
>>>>
>>>><parameter name="something">
>>>><deprecated message="Use somethingElse parameter"/>
>>>>
>>>>...
>>>>
>>>>e.g. there is a thread on the -user list at the moment about merging
>>>>Insert and InsertText. If deemed a good idea, it would be nice to
>>>>deprecate the InsertText component, leaving it in Tapestry 4, and
>>>>removing it from the next significant release.
>>>>
>>>>Any thoughts?
>>>>
>>>>Richard
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>--
>>Howard M. Lewis Ship
>>Independent J2EE / Open-Source Java Consultant
>>Creator, Jakarta Tapestry
>>Creator, Jakarta HiveMind
>>
>>Professional Tapestry training, mentoring, support
>>and project work. http://howardlewisship.com 
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating components

Howard Lewis Ship
Yes, using an alias will generate some kind of warning (on the console).

On 5/18/05, Richard Lewis-Shell <[hidden email]> wrote:

> parameter aliases would be implicitly deprecated right?
>
> Howard Lewis Ship wrote:
> > I've also been thinking about having a list of "aliases" for parameters, for
> > when we want to give them better names.
> >
> > On 5/15/05, Howard Lewis Ship <[hidden email]> wrote:
> >
> >>I've been thinking about this too; including a deprecation service that
> >>would log the deprecation warnings ... but just once, so you don't get
> >>flooded.
> >>
> >>On 5/14/05, Jamie Orchard-Hays <[hidden email]> wrote:
> >>
> >>>I like this idea. It would definitely be useful.
> >>>
> >>>Jamie
> >>>
> >>>
> >>>On May 14, 2005, at 5:15 AM, Richard Lewis-Shell wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>I am thinking it would be useful to add support to Tapestry for
> >>>>deprecating components, so that we can provide a clear migration path
> >>>>for changing components. It can imagine it would be useful to be able
> >>>>to deprecate an entire component and/or individual component
> >>>>parameters, and have Tapestry display a warning when such
> >>>>components/parameters are constructed. It would probably be desirable
> >>>>to be able to disable those warning messages, perhaps via a system
> >>>>property. Off the top of my head, it might look like this:
> >>>>
> >>>>Foo.jwc:
> >>>><component-specification ...>
> >>>><deprecated message="Use the simpler Bar component instead of Foo"/>
> >>>>
> >>>><parameter name="something">
> >>>><deprecated message="Use somethingElse parameter"/>
> >>>>
> >>>>...
> >>>>
> >>>>e.g. there is a thread on the -user list at the moment about merging
> >>>>Insert and InsertText. If deemed a good idea, it would be nice to
> >>>>deprecate the InsertText component, leaving it in Tapestry 4, and
> >>>>removing it from the next significant release.
> >>>>
> >>>>Any thoughts?
> >>>>
> >>>>Richard
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: [hidden email]
> >>>>For additional commands, e-mail: [hidden email]
> >>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >>
> >>--
> >>Howard M. Lewis Ship
> >>Independent J2EE / Open-Source Java Consultant
> >>Creator, Jakarta Tapestry
> >>Creator, Jakarta HiveMind
> >>
> >>Professional Tapestry training, mentoring, support
> >>and project work. http://howardlewisship.com
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]