You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Robin Komiwes <ro...@gmail.com> on 2010/04/22 14:20:31 UTC
About components, mixins and pages : designing for extensibility
Hi,
As I said before here, I'm working on a port of tapestry.js to jQuery.
Instead of just having to recode tapestry.js, I'm too often obliged to fork
core components for a little and annoying thing : the
@IncludeJavaScriptLibrary and @IncludeStylesheet annotations, just in order
to be able to change path of theses assets.
As it is made for Autocomplete mixins, why not using this kind of coding
style for JS and CSS inclusion:
/**
* @param config
* parameters object
*/
protected void configure(JSONObject config)
{
}
In the current case, it may look like:
protected void include()
{
renderSupport.addScript("script.js");
renderSupport.addStylesheetLink("style.css", "print");
}
It would provide easier extensibility for components, mixins and pages.
Anyway, this is just my feedback about this technical aspect of Tapestry 5.
:)
Regards,
Robin
Re: About components, mixins and pages : designing for extensibility
Posted by Christophe Cordenier <ch...@gmail.com>.
oh, ok.
This was one the main question we had with Robin K. when he started to
develop the tapestry-jquery
<http://github.com/got5/tapestry5-jquery>contribution.
But we had made slightly different choices because its solution has been
designed to work with tapestry 5.1 too
2010/4/22 Howard Lewis Ship <hl...@gmail.com>
> I see it as a thin layer on top of a real framework.
>
> So maybe there will be a Tapestry.observe() function that acts much
> like Prototype's Event.observe() but can also map to jQuery $().on()
> (working from memory on the last that).
>
> On Thu, Apr 22, 2010 at 8:54 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > Hi
> >
> > 2010/4/22 Howard Lewis Ship <hl...@gmail.com>
> >
> >> My goal for tapestry.js is that add on libraries, such as palette.js,
> >> would be coded in terms of tapestry.js and not prototype or jquery.
> >> Hopefully that's a reachable goal. This is something I may pursue
> >> again soon.
> >>
> >
> > Does this mean that tapestry.js will become a javascript framework; or
> will
> > it be an agnostic layer, and then tapestry will provide some kind of
> drivers
> > for other technologies like jquery, extjs... ?
> >
> > Sorry if my question is totally out of scope...
> >
> > Regards
> > Christophe Cordenier.
> >
> >
> >> I also have plans to rework a lot of the existing JavaScript from
> >> "java-in-javascript" style (the Prototype way, creating new classes)
> >> to a more functional way (everything is based on events on elements).
> >> That latter part should also make it easier to substitute one layer
> >> for another.
> >>
> >> On Thu, Apr 22, 2010 at 5:48 AM, Thiago H. de Paula Figueiredo
> >> <th...@gmail.com> wrote:
> >> > On Thu, 22 Apr 2010 09:20:31 -0300, Robin Komiwes <
> >> robin.komiwes@gmail.com>
> >> > wrote:
> >> >
> >> >> Hi,
> >> >
> >> > Hi!
> >> >
> >> >> As it is made for Autocomplete mixins, why not using this kind of
> coding
> >> >> style for JS and CSS inclusion:
> >> >> /**
> >> >> * @param config
> >> >> * parameters object
> >> >> */
> >> >> protected void configure(JSONObject config)
> >> >> {
> >> >> }
> >> >
> >> > Then Tapestry components wouldn't be JavaScript stack-agnostic, as you
> >> would
> >> > need a PrototypeAutocomplete and a JQueryAutocomplete. Why not use
> normal
> >> > parameters for stuff that can be configured?
> >> >
> >> > Howard already stated that he doesn't think subclassing Tapestry
> >> components
> >> > is a good idea, as it would be harder to improve them without breaking
> >> > backward compatibility.
> >> >
> >> > --
> >> > Thiago H. de Paula Figueiredo
> >> > Independent Java, Apache Tapestry 5 and Hibernate consultant,
> developer,
> >> and
> >> > instructor
> >> > Owner, software architect and developer, Ars Machina Tecnologia da
> >> > Informação Ltda.
> >> > http://www.arsmachina.com.br
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Howard M. Lewis Ship
> >>
> >> Creator of Apache Tapestry
> >>
> >> The source for Tapestry training, mentoring and support. Contact me to
> >> learn how I can get you up and productive in Tapestry fast!
> >>
> >> (971) 678-5210
> >> http://howardlewisship.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Regards,
> > Christophe Cordenier.
> >
> > Developer of wooki @wookicentral.com
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: About components, mixins and pages : designing for extensibility
Posted by Howard Lewis Ship <hl...@gmail.com>.
I see it as a thin layer on top of a real framework.
So maybe there will be a Tapestry.observe() function that acts much
like Prototype's Event.observe() but can also map to jQuery $().on()
(working from memory on the last that).
On Thu, Apr 22, 2010 at 8:54 AM, Christophe Cordenier
<ch...@gmail.com> wrote:
> Hi
>
> 2010/4/22 Howard Lewis Ship <hl...@gmail.com>
>
>> My goal for tapestry.js is that add on libraries, such as palette.js,
>> would be coded in terms of tapestry.js and not prototype or jquery.
>> Hopefully that's a reachable goal. This is something I may pursue
>> again soon.
>>
>
> Does this mean that tapestry.js will become a javascript framework; or will
> it be an agnostic layer, and then tapestry will provide some kind of drivers
> for other technologies like jquery, extjs... ?
>
> Sorry if my question is totally out of scope...
>
> Regards
> Christophe Cordenier.
>
>
>> I also have plans to rework a lot of the existing JavaScript from
>> "java-in-javascript" style (the Prototype way, creating new classes)
>> to a more functional way (everything is based on events on elements).
>> That latter part should also make it easier to substitute one layer
>> for another.
>>
>> On Thu, Apr 22, 2010 at 5:48 AM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>> > On Thu, 22 Apr 2010 09:20:31 -0300, Robin Komiwes <
>> robin.komiwes@gmail.com>
>> > wrote:
>> >
>> >> Hi,
>> >
>> > Hi!
>> >
>> >> As it is made for Autocomplete mixins, why not using this kind of coding
>> >> style for JS and CSS inclusion:
>> >> /**
>> >> * @param config
>> >> * parameters object
>> >> */
>> >> protected void configure(JSONObject config)
>> >> {
>> >> }
>> >
>> > Then Tapestry components wouldn't be JavaScript stack-agnostic, as you
>> would
>> > need a PrototypeAutocomplete and a JQueryAutocomplete. Why not use normal
>> > parameters for stuff that can be configured?
>> >
>> > Howard already stated that he doesn't think subclassing Tapestry
>> components
>> > is a good idea, as it would be harder to improve them without breaking
>> > backward compatibility.
>> >
>> > --
>> > Thiago H. de Paula Figueiredo
>> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and
>> > instructor
>> > Owner, software architect and developer, Ars Machina Tecnologia da
>> > Informação Ltda.
>> > http://www.arsmachina.com.br
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: dev-help@tapestry.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Developer of wooki @wookicentral.com
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: About components, mixins and pages : designing for extensibility
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi
2010/4/22 Howard Lewis Ship <hl...@gmail.com>
> My goal for tapestry.js is that add on libraries, such as palette.js,
> would be coded in terms of tapestry.js and not prototype or jquery.
> Hopefully that's a reachable goal. This is something I may pursue
> again soon.
>
Does this mean that tapestry.js will become a javascript framework; or will
it be an agnostic layer, and then tapestry will provide some kind of drivers
for other technologies like jquery, extjs... ?
Sorry if my question is totally out of scope...
Regards
Christophe Cordenier.
> I also have plans to rework a lot of the existing JavaScript from
> "java-in-javascript" style (the Prototype way, creating new classes)
> to a more functional way (everything is based on events on elements).
> That latter part should also make it easier to substitute one layer
> for another.
>
> On Thu, Apr 22, 2010 at 5:48 AM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
> > On Thu, 22 Apr 2010 09:20:31 -0300, Robin Komiwes <
> robin.komiwes@gmail.com>
> > wrote:
> >
> >> Hi,
> >
> > Hi!
> >
> >> As it is made for Autocomplete mixins, why not using this kind of coding
> >> style for JS and CSS inclusion:
> >> /**
> >> * @param config
> >> * parameters object
> >> */
> >> protected void configure(JSONObject config)
> >> {
> >> }
> >
> > Then Tapestry components wouldn't be JavaScript stack-agnostic, as you
> would
> > need a PrototypeAutocomplete and a JQueryAutocomplete. Why not use normal
> > parameters for stuff that can be configured?
> >
> > Howard already stated that he doesn't think subclassing Tapestry
> components
> > is a good idea, as it would be harder to improve them without breaking
> > backward compatibility.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and
> > instructor
> > Owner, software architect and developer, Ars Machina Tecnologia da
> > Informação Ltda.
> > http://www.arsmachina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: About components, mixins and pages : designing for extensibility
Posted by Howard Lewis Ship <hl...@gmail.com>.
My goal for tapestry.js is that add on libraries, such as palette.js,
would be coded in terms of tapestry.js and not prototype or jquery.
Hopefully that's a reachable goal. This is something I may pursue
again soon.
I also have plans to rework a lot of the existing JavaScript from
"java-in-javascript" style (the Prototype way, creating new classes)
to a more functional way (everything is based on events on elements).
That latter part should also make it easier to substitute one layer
for another.
On Thu, Apr 22, 2010 at 5:48 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Thu, 22 Apr 2010 09:20:31 -0300, Robin Komiwes <ro...@gmail.com>
> wrote:
>
>> Hi,
>
> Hi!
>
>> As it is made for Autocomplete mixins, why not using this kind of coding
>> style for JS and CSS inclusion:
>> /**
>> * @param config
>> * parameters object
>> */
>> protected void configure(JSONObject config)
>> {
>> }
>
> Then Tapestry components wouldn't be JavaScript stack-agnostic, as you would
> need a PrototypeAutocomplete and a JQueryAutocomplete. Why not use normal
> parameters for stuff that can be configured?
>
> Howard already stated that he doesn't think subclassing Tapestry components
> is a good idea, as it would be harder to improve them without breaking
> backward compatibility.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, software architect and developer, Ars Machina Tecnologia da
> Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: About components, mixins and pages : designing for extensibility
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 22 Apr 2010 09:20:31 -0300, Robin Komiwes
<ro...@gmail.com> wrote:
> Hi,
Hi!
> As it is made for Autocomplete mixins, why not using this kind of coding
> style for JS and CSS inclusion:
> /**
> * @param config
> * parameters object
> */
> protected void configure(JSONObject config)
> {
> }
Then Tapestry components wouldn't be JavaScript stack-agnostic, as you
would need a PrototypeAutocomplete and a JQueryAutocomplete. Why not use
normal parameters for stuff that can be configured?
Howard already stated that he doesn't think subclassing Tapestry
components is a good idea, as it would be harder to improve them without
breaking backward compatibility.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org