You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2007/10/03 03:22:53 UTC
Prototype vs. JQuery vs. Dojo 0.9 vs. ???
I've been having some fun wrapping my brain around JQuery.
I'm not fully certain its a great fit however.
For hand-tooled web pages, maybe traditional JSPs, it would be perfectly
good.
But it's really built around identifying elements that need "special
attention" in terms of CSS class and page structure, and then applying
uniform effects and logic (in the form of even handlers) to them.
Tapestry is more geared towards the server side "seeding" the client side
with specific element ids, and then hooking up the appropriate event handler
that way.
In fact, that is more Protoype's angle, the whole point of $("myid") being
so easy. JQuery lets you use Document.getElementById() ... it's one area
where the $() function has no great magic.
Can Tapestry shift? Should it? Would the newly revised Dojo be a better
fit?
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by liigo <co...@gmail.com>.
2007/10/3, Howard Lewis Ship <hl...@gmail.com>:
>
> In fact, that is more Protoype's angle, the whole point of $("myid") being
> so easy. JQuery lets you use Document.getElementById() ... it's one area
> where the $() function has no great magic.
$("#id") or $("#id")[0] is the same as Document.getElementById(), in jQuery.
2007/10/3, Jesse Kuhnert <jk...@gmail.com>:
>
> I think forcing anyone to pick one library is a mistake.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Joost Schouten <jo...@jsportal.com>.
I should have replied on the first post as I was replying to give your
answer more weight not oppose it ;-)
Cheers,
Joost
-----Original Message-----
From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf Of andyhot
Sent: Wednesday, October 03, 2007 4:58 PM
To: Tapestry development
Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
I think you're misunderstanding my intentions :)
Here are the facts the way i see them:
- Tapestry needs some js functions for its own use, hence tapestry.js
- I do NOT want to force users (not even myself) to go through
tapestry.js - they should be able to
use the library they want to
- I do NOT want to force users to have to load another library simply
because tapestry.js needs it
And here's where i'd be heading at:
- Plan js usage in such a way that alternatives to tapestry.js (such as
tapestry-yui.js or tapestry-jquery.js,
or even tapestry-donothing.js) are easy to write and even easier to include
For the record, i'm close to the tapestry-donothing.js step for T4.
Joost Schouten wrote:
> Hi,
>
> I see huge potential for build in AJAX with tapestry. Component reloading
is
> something which wasn't too hard to implement. But I would not like to be
> locked in, or have the framework of choice included even if I don't need
it
> (love your script loading feature btw).
>
> I am a big fan of making my own choices in this area. Martin Reurings
> recently posted about this in the user group:
> http://www.nabble.com/T5:-using-DOJO--t4368411.html#a12869068 I strongly
> agree and would love to see this kind of granularity. Making a tapestry.js
> as a wrapper for any framework seems more a confinement than an addition.
> I'd rather see a clean tapestry module without any client side scripting
and
> potentially one or more modules using the framework of choice.
>
> We already had to do some cutting to have Tapestry leave the scripting to
> us. I hope Tapestry won't make the same mistake a lot of JSF
implementations
> have made.
>
> Cheers,
> Joost
>
>
> We have just stripped T5 completely of all it's javascript as it was
causing
>
>
> -----Original Message-----
> From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf Of andyhot
> Sent: Wednesday, October 03, 2007 2:46 PM
> To: Tapestry development
> Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
>
> In my mind there's only one correct answer for Tapestry to this:
> nothing and everything!
>
> ext is looking great these days, yui is ... yahoo, dojo 0.9-1.0 is sooo
> improved
> and prototype is ... the good old prototype - and who knows what's to come
>
> If anyone's been looking at my recent 4.1 commits, i've set to abstract
> all dojo calls through
> the tapestry object - and i've been able to do this by introducing just
> 6-7 more functions in it.
> And i can now replace dojo with other libraries - i expect a few more
> technical challenges, but
> it should be straightforward to work
>
> So, perhaps this would prove as a guide for T5 as well
>
>
> Howard Lewis Ship wrote:
>
>> I've been having some fun wrapping my brain around JQuery.
>>
>> I'm not fully certain its a great fit however.
>>
>> For hand-tooled web pages, maybe traditional JSPs, it would be perfectly
>> good.
>>
>> But it's really built around identifying elements that need "special
>> attention" in terms of CSS class and page structure, and then applying
>> uniform effects and logic (in the form of even handlers) to them.
>>
>> Tapestry is more geared towards the server side "seeding" the client side
>> with specific element ids, and then hooking up the appropriate event
>>
> handler
>
>> that way.
>>
>> In fact, that is more Protoype's angle, the whole point of $("myid")
being
>> so easy. JQuery lets you use Document.getElementById() ... it's one area
>> where the $() function has no great magic.
>>
>> Can Tapestry shift? Should it? Would the newly revised Dojo be a better
>> fit?
>>
>>
>>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by jblier <ja...@airwidesolutions.com>.
The ExtJS library (1.1.1) have examples where the user select between a
choice of existing JS libraries in a popup.
See: http://extjs.com/deploy/ext/examples/dialog/hello.html
He is supporting:
- Ext Stand-alone
- Yahoo UI Utiliites
- jQuery
- Prototype+Scriptaculous
Version 2.0 doesn't support Library switching.
In general I find ExtJS way too slow for any production environment.
- Jacques
Howard Lewis Ship wrote:
>
> I think we may want to cut a branch (or two) to experiment on this.
>
> Basic operations:
>
> - validate field (on submit? on loss of focus?)
> - declarative validation ala T4.1? aka the json blob
> - hide element (instant)
> - fade element (animated)
> - reveal element (instant)
> - fadeIn element (animated)
> - page loaded initialization
> - bind a function as an event handler of an element
> - basic Ajax support, including partial updates (more json)
>
> Basically, enough to support validation, Palette, some kind of
> calendar/date input, etc.
>
> I think we're falling towards a strategy pattern here.
>
> I'd like things to just work to a significant degree.
>
> Configuration would determine the flavor ("jquery", "dojo",
> "prototype", "minimal", etc.).
>
> This configuration would do two things:
> - inject the correct set of libraries (as prototype/scriptaculous is done
> today)
> - Inject the correct adapter library (i.e., tapestry-jquery.js,
> tapestry-dojo.js, etc.)
>
> The different adapters would have the same functions, defined in terms
> of the flavor.
>
> Flavor would be configured on a per-application basis. Maybe ... or
> it could be determined on the fly during the render which would allow
> us to identify impossible configurations (as in jquery vs. prototype,
> etc.).
>
> I really think that the amount of Ajax rolled into the framework will
> be relatively simple, and serious Tapestry/Ajax will be a bit more
> about a good foundation and cookbook.
>
> I'm concerned about certain dynamics, such as: if a field is
> non-visible on the client it should bypass validation. How does the
> server know it is not visible, so that server validations can be
> bypassed?
>
> Forms are just in general tricky, I think we should support just
> show/hide within a form, and the addition of new elements to a form
> (think: add a new line item to an invoice), but not much trickier than
> that.
>
> Jesse and I had discussed coming up with a shopping list of Ajax Use
> Cases to be supported. Let's start there!
>
> On 10/3/07, Ben Sommerville <be...@bulletproof.com.au> wrote:
>> No, I wasn't going that far.
>>
>> More that the core library would never directly generate
>> javascript, but instead call a pluggable interface for the
>> required functionality. The module that implemented that
>> interface would then output the required javascript
>>
>> I would see those interfaces as "intention" driven rather
>> than functional driven. That is they would be based on
>> the task the core is trying to accomplish rather than
>> the features/functions of available javascript libraries.
>>
>> Its all very fuzzy at the moment & I think it would need
>> a bit of trial & error to get right.
>>
>> cheers,
>> Ben
>>
>> > -----Original Message-----
>> > From: Julien HENRY [mailto:henryju@yahoo.fr]
>> > Sent: Wednesday, 3 October 2007 10:03 PM
>> > To: Tapestry development
>> > Subject: RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
>> >
>> > @Ben: Do you think about something like GWT? I mean
>> > programming JavaScript in Java.
>> >
>> > Components (especially AJAX ones) will certainly use
>> > various existing JavaScript libraries. I think the
>> > main issue is "what about T5 core components?". Should
>> > they use a specific library (without preventing
>> > additional components for using their own)?
>> >
>> > Don't know what could be the best solution... sorry.
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
> Partner and Senior Architect at Feature50
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Prototype-vs.-JQuery-vs.-Dojo-0.9-vs.-----tf4559353.html#a13045537
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think we may want to cut a branch (or two) to experiment on this.
Basic operations:
- validate field (on submit? on loss of focus?)
- declarative validation ala T4.1? aka the json blob
- hide element (instant)
- fade element (animated)
- reveal element (instant)
- fadeIn element (animated)
- page loaded initialization
- bind a function as an event handler of an element
- basic Ajax support, including partial updates (more json)
Basically, enough to support validation, Palette, some kind of
calendar/date input, etc.
I think we're falling towards a strategy pattern here.
I'd like things to just work to a significant degree.
Configuration would determine the flavor ("jquery", "dojo",
"prototype", "minimal", etc.).
This configuration would do two things:
- inject the correct set of libraries (as prototype/scriptaculous is done today)
- Inject the correct adapter library (i.e., tapestry-jquery.js,
tapestry-dojo.js, etc.)
The different adapters would have the same functions, defined in terms
of the flavor.
Flavor would be configured on a per-application basis. Maybe ... or
it could be determined on the fly during the render which would allow
us to identify impossible configurations (as in jquery vs. prototype,
etc.).
I really think that the amount of Ajax rolled into the framework will
be relatively simple, and serious Tapestry/Ajax will be a bit more
about a good foundation and cookbook.
I'm concerned about certain dynamics, such as: if a field is
non-visible on the client it should bypass validation. How does the
server know it is not visible, so that server validations can be
bypassed?
Forms are just in general tricky, I think we should support just
show/hide within a form, and the addition of new elements to a form
(think: add a new line item to an invoice), but not much trickier than
that.
Jesse and I had discussed coming up with a shopping list of Ajax Use
Cases to be supported. Let's start there!
On 10/3/07, Ben Sommerville <be...@bulletproof.com.au> wrote:
> No, I wasn't going that far.
>
> More that the core library would never directly generate
> javascript, but instead call a pluggable interface for the
> required functionality. The module that implemented that
> interface would then output the required javascript
>
> I would see those interfaces as "intention" driven rather
> than functional driven. That is they would be based on
> the task the core is trying to accomplish rather than
> the features/functions of available javascript libraries.
>
> Its all very fuzzy at the moment & I think it would need
> a bit of trial & error to get right.
>
> cheers,
> Ben
>
> > -----Original Message-----
> > From: Julien HENRY [mailto:henryju@yahoo.fr]
> > Sent: Wednesday, 3 October 2007 10:03 PM
> > To: Tapestry development
> > Subject: RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
> >
> > @Ben: Do you think about something like GWT? I mean
> > programming JavaScript in Java.
> >
> > Components (especially AJAX ones) will certainly use
> > various existing JavaScript libraries. I think the
> > main issue is "what about T5 core components?". Should
> > they use a specific library (without preventing
> > additional components for using their own)?
> >
> > Don't know what could be the best solution... sorry.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Ben Sommerville <be...@bulletproof.com.au>.
No, I wasn't going that far.
More that the core library would never directly generate
javascript, but instead call a pluggable interface for the
required functionality. The module that implemented that
interface would then output the required javascript
I would see those interfaces as "intention" driven rather
than functional driven. That is they would be based on
the task the core is trying to accomplish rather than
the features/functions of available javascript libraries.
Its all very fuzzy at the moment & I think it would need
a bit of trial & error to get right.
cheers,
Ben
> -----Original Message-----
> From: Julien HENRY [mailto:henryju@yahoo.fr]
> Sent: Wednesday, 3 October 2007 10:03 PM
> To: Tapestry development
> Subject: RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
>
> @Ben: Do you think about something like GWT? I mean
> programming JavaScript in Java.
>
> Components (especially AJAX ones) will certainly use
> various existing JavaScript libraries. I think the
> main issue is "what about T5 core components?". Should
> they use a specific library (without preventing
> additional components for using their own)?
>
> Don't know what could be the best solution... sorry.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Davor Hrg <hr...@gmail.com>.
Making an abstraction layer can have another advantage:
set of unit tests for a specific implementation, so that new libraries
can be more rebust from the first impl.
some general approaches to building web pages should be listed and
considered.
pure html
separate pages with some js
"single" page that loads all with AJAX (not all content from the start, just
as needed)
...other ....
Davor Hrg
On 10/3/07, Ben Sommerville <be...@bulletproof.com.au> wrote:
>
> I've been mulling on this topic for a while since I'm working
> (intermittently)
> on a project that uses JQuery & Tap5.
>
> I would love it if Tapestry core was not coupled to any particular
> javascript
> library & could also be used without any javascript at all.
>
> Obviously to do this we'd need to introduce an abstraction/indirection
> layer
> for the parts of tapestry that may use javascript. The two approaches I
> see
> are:
> a) Define a java api for invoking/using/generating javascript that
> Tapestry
> core uses, then create modules for each javascript library
> (as Joost suggested)
> b) Define an javascript api that Tapestry invokes then create
> implementations
> of that for various javascript libraries
> (as Andreas suggested)
>
> My preference is the first approach for a couple of reasons:
> - it forces a strict separation. Tapestry core never directly constructs
> javascript so there is no chance it will use functions/etc from a
> particular
> library
> - it means that there can be a lot more freedom on how the javascript is
> written. e.g. field validations could be accumulated & written out as a
> JSON data type, added directly to elements via css/custom attributes or
> accumulated via function calls (as is done presently).
> - tapestry core makes no assumptions about the client side environment. I
>
> can see this being a benefit when dealing with other platforms such as
> mobile phones.
>
> On the downside it may be harder to construct a good java api that covers
> all the possibilities. However that is no reason not to try! :)
>
>
> cheers
> Ben
>
>
> > -----Original Message-----
> > From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf Of andyhot
> > Sent: Wednesday, 3 October 2007 1:58 PM
> > To: Tapestry development
> > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
> >
> > I think you're misunderstanding my intentions :)
> >
> > Here are the facts the way i see them:
> > - Tapestry needs some js functions for its own use, hence tapestry.js
> > - I do NOT want to force users (not even myself) to go through
> > tapestry.js - they should be able to
> > use the library they want to
> > - I do NOT want to force users to have to load another library simply
> > because tapestry.js needs it
> >
> > And here's where i'd be heading at:
> > - Plan js usage in such a way that alternatives to
> > tapestry.js (such as
> > tapestry-yui.js or tapestry-jquery.js,
> > or even tapestry-donothing.js) are easy to write and even
> > easier to include
> >
> > For the record, i'm close to the tapestry-donothing.js step for T4.
> >
> > Joost Schouten wrote:
> > > Hi,
> > >
> > > I see huge potential for build in AJAX with tapestry.
> > Component reloading is
> > > something which wasn't too hard to implement. But I would
> > not like to be
> > > locked in, or have the framework of choice included even if
> > I don't need it
> > > (love your script loading feature btw).
> > >
> > > I am a big fan of making my own choices in this area.
> > Martin Reurings
> > > recently posted about this in the user group:
> > >
> > http://www.nabble.com/T5:-using-DOJO--t4368411.html#a12869068
> > I strongly
> > > agree and would love to see this kind of granularity.
> > Making a tapestry.js
> > > as a wrapper for any framework seems more a confinement
> > than an addition.
> > > I'd rather see a clean tapestry module without any client
> > side scripting and
> > > potentially one or more modules using the framework of choice.
> > >
> > > We already had to do some cutting to have Tapestry leave
> > the scripting to
> > > us. I hope Tapestry won't make the same mistake a lot of
> > JSF implementations
> > > have made.
> > >
> > > Cheers,
> > > Joost
> > >
> > >
> > > We have just stripped T5 completely of all it's javascript
> > as it was causing
> > >
> > >
> > > -----Original Message-----
> > > From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf
> > Of andyhot
> > > Sent: Wednesday, October 03, 2007 2:46 PM
> > > To: Tapestry development
> > > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
> > >
> > > In my mind there's only one correct answer for Tapestry to this:
> > > nothing and everything!
> > >
> > > ext is looking great these days, yui is ... yahoo, dojo
> > 0.9-1.0 is sooo
> > > improved
> > > and prototype is ... the good old prototype - and who knows
> > what's to come
> > >
> > > If anyone's been looking at my recent 4.1 commits, i've set
> > to abstract
> > > all dojo calls through
> > > the tapestry object - and i've been able to do this by
> > introducing just
> > > 6-7 more functions in it.
> > > And i can now replace dojo with other libraries - i expect
> > a few more
> > > technical challenges, but
> > > it should be straightforward to work
> > >
> > > So, perhaps this would prove as a guide for T5 as well
> > >
> > >
> > > Howard Lewis Ship wrote:
> > >
> > >> I've been having some fun wrapping my brain around JQuery.
> > >>
> > >> I'm not fully certain its a great fit however.
> > >>
> > >> For hand-tooled web pages, maybe traditional JSPs, it
> > would be perfectly
> > >> good.
> > >>
> > >> But it's really built around identifying elements that
> > need "special
> > >> attention" in terms of CSS class and page structure, and
> > then applying
> > >> uniform effects and logic (in the form of even handlers) to them.
> > >>
> > >> Tapestry is more geared towards the server side "seeding"
> > the client side
> > >> with specific element ids, and then hooking up the
> > appropriate event
> > >>
> > > handler
> > >
> > >> that way.
> > >>
> > >> In fact, that is more Protoype's angle, the whole point of
> > $("myid") being
> > >> so easy. JQuery lets you use Document.getElementById()
> > ... it's one area
> > >> where the $() function has no great magic.
> > >>
> > >> Can Tapestry shift? Should it? Would the newly revised
> > Dojo be a better
> > >> fit?
> > >>
> > >>
> > >>
> > >
> > >
> >
> > --
> > Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> > Tapestry / Tacos developer
> > Open Source / JEE Consulting
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
just my 2 cent:
<IMHO>
i'd vote for a solution that creates a javascript abstraction layer.
not a single tapestry component should generate the javascript
code itself but delegate it to this layer. The only information this
layer would need is the generated id of the component and some
meta information.
this unique approach would give Tapestry 5 a competitive advantage
over other web frameworks as it could support multiple javascript
libraries.
because the importance of client side scripting rises (or is already high)
and the complexity and size of generated pages rises too the choice for
the *right* javascript library may be crucial for a responsive ui. from my
experience using dojo 0.4.2 for big uis can degrade the user experience
and responisvenss due to long loading times (compared to other libraries),
and awkward implementations within the library (not to mention the usage
of
the dojo api compared to jquery's api)
i also think such an abstraction layer would allow optimizations of the
client side javascript code. for example you could apply event delegation
for certain parts of the generated page (actionlinks within a loop, or
table).
furthermore i hope several 3rd party components will emerge using this
abstraction layer to deliver rich javascript components :)
Tapestry (Howard) emphasizes separation of concerns therefore a javascript
abstraction layer - from my point of view - is the way go .. :)
but i don't know what default library to choose. i'd probably go for
prototype...
it offers the necessary api for event handling, ajax, using css selectors
for
retrieving dom nodes... and is small....
.. although i haven't looked at dojo 0.9 recently.
... and jquerys plugin mechanism has more appeal than dojos require
</IMHO>
g,
kris
Julien HENRY <he...@yahoo.fr>
03.10.2007 14:02
Bitte antworten an
"Tapestry development" <de...@tapestry.apache.org>
An
Tapestry development <de...@tapestry.apache.org>
Kopie
Thema
RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
@Ben: Do you think about something like GWT? I mean
programming JavaScript in Java.
Components (especially AJAX ones) will certainly use
various existing JavaScript libraries. I think the
main issue is "what about T5 core components?". Should
they use a specific library (without preventing
additional components for using their own)?
Don't know what could be the best solution... sorry.
--- Ben Sommerville <be...@bulletproof.com.au> a écrit :
> I've been mulling on this topic for a while since
> I'm working
> (intermittently)
> on a project that uses JQuery & Tap5.
>
> I would love it if Tapestry core was not coupled to
> any particular
> javascript
> library & could also be used without any javascript
> at all.
>
> Obviously to do this we'd need to introduce an
> abstraction/indirection
> layer
> for the parts of tapestry that may use javascript.
> The two approaches I
> see
> are:
> a) Define a java api for invoking/using/generating
> javascript that
> Tapestry
> core uses, then create modules for each
> javascript library
> (as Joost suggested)
> b) Define an javascript api that Tapestry invokes
> then create
> implementations
> of that for various javascript libraries
> (as Andreas suggested)
>
> My preference is the first approach for a couple of
> reasons:
> - it forces a strict separation. Tapestry core
> never directly constructs
> javascript so there is no chance it will use
> functions/etc from a
> particular
> library
> - it means that there can be a lot more freedom on
> how the javascript is
> written. e.g. field validations could be
> accumulated & written out as a
> JSON data type, added directly to elements via
> css/custom attributes or
> accumulated via function calls (as is done
> presently).
> - tapestry core makes no assumptions about the
> client side environment. I
>
> can see this being a benefit when dealing with other
> platforms such as
> mobile phones.
>
> On the downside it may be harder to construct a good
> java api that covers
> all the possibilities. However that is no reason not
> to try! :)
>
>
> cheers
> Ben
>
>
> > -----Original Message-----
> > From: Andreas Andreou [mailto:andreoua@gmail.com]
> On Behalf Of andyhot
> > Sent: Wednesday, 3 October 2007 1:58 PM
> > To: Tapestry development
> > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs.
> ???
> >
> > I think you're misunderstanding my intentions :)
> >
> > Here are the facts the way i see them:
> > - Tapestry needs some js functions for its own
> use, hence tapestry.js
> > - I do NOT want to force users (not even myself)
> to go through
> > tapestry.js - they should be able to
> > use the library they want to
> > - I do NOT want to force users to have to load
> another library simply
> > because tapestry.js needs it
> >
> > And here's where i'd be heading at:
> > - Plan js usage in such a way that alternatives to
>
> > tapestry.js (such as
> > tapestry-yui.js or tapestry-jquery.js,
> > or even tapestry-donothing.js) are easy to write
> and even
> > easier to include
> >
> > For the record, i'm close to the
> tapestry-donothing.js step for T4.
> >
> > Joost Schouten wrote:
> > > Hi,
> > >
> > > I see huge potential for build in AJAX with
> tapestry.
> > Component reloading is
> > > something which wasn't too hard to implement.
> But I would
> > not like to be
> > > locked in, or have the framework of choice
> included even if
> > I don't need it
> > > (love your script loading feature btw).
> > >
> > > I am a big fan of making my own choices in this
> area.
> > Martin Reurings
> > > recently posted about this in the user group:
> > >
> >
>
http://www.nabble.com/T5:-using-DOJO--t4368411.html#a12869068
>
> > I strongly
> > > agree and would love to see this kind of
> granularity.
> > Making a tapestry.js
> > > as a wrapper for any framework seems more a
> confinement
> > than an addition.
> > > I'd rather see a clean tapestry module without
> any client
> > side scripting and
> > > potentially one or more modules using the
> framework of choice.
> > >
> > > We already had to do some cutting to have
> Tapestry leave
> > the scripting to
> > > us. I hope Tapestry won't make the same mistake
> a lot of
> > JSF implementations
> > > have made.
> > >
> > > Cheers,
> > > Joost
> > >
> > >
> > > We have just stripped T5 completely of all it's
> javascript
> > as it was causing
> > >
> > >
> > > -----Original Message-----
> > > From: Andreas Andreou
> [mailto:andreoua@gmail.com] On Behalf
> > Of andyhot
> > > Sent: Wednesday, October 03, 2007 2:46 PM
> > > To: Tapestry development
> > > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9
> vs. ???
> > >
> > > In my mind there's only one correct answer for
> Tapestry to this:
> > > nothing and everything!
> > >
> > > ext is looking great these days, yui is ...
> yahoo, dojo
> > 0.9-1.0 is sooo
> > > improved
> > > and prototype is ... the good old prototype -
> and who knows
> > what's to come
> > >
> > > If anyone's been looking at my recent 4.1
> commits, i've set
> > to abstract
> > > all dojo calls through
> > > the tapestry object - and i've been able to do
> this by
> > introducing just
> > > 6-7 more functions in it.
> > > And i can now replace dojo with other libraries
> - i expect
> > a few more
> > > technical challenges, but
> > > it should be straightforward to work
> > >
> > > So, perhaps this would prove as a guide for T5
> as well
> > >
> > >
> > > Howard Lewis Ship wrote:
> > >
> > >> I've been having some fun wrapping my brain
> around JQuery.
> > >>
> > >> I'm not fully certain its a great fit however.
> > >>
> > >> For hand-tooled web pages, maybe traditional
> JSPs, it
> > would be perfectly
> > >> good.
> > >>
> > >> But it's really built around identifying
> elements that
>
=== message truncated ===
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo!
Mail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Julien HENRY <he...@yahoo.fr>.
@Ben: Do you think about something like GWT? I mean
programming JavaScript in Java.
Components (especially AJAX ones) will certainly use
various existing JavaScript libraries. I think the
main issue is "what about T5 core components?". Should
they use a specific library (without preventing
additional components for using their own)?
Don't know what could be the best solution... sorry.
--- Ben Sommerville <be...@bulletproof.com.au> a écrit :
> I've been mulling on this topic for a while since
> I'm working
> (intermittently)
> on a project that uses JQuery & Tap5.
>
> I would love it if Tapestry core was not coupled to
> any particular
> javascript
> library & could also be used without any javascript
> at all.
>
> Obviously to do this we'd need to introduce an
> abstraction/indirection
> layer
> for the parts of tapestry that may use javascript.
> The two approaches I
> see
> are:
> a) Define a java api for invoking/using/generating
> javascript that
> Tapestry
> core uses, then create modules for each
> javascript library
> (as Joost suggested)
> b) Define an javascript api that Tapestry invokes
> then create
> implementations
> of that for various javascript libraries
> (as Andreas suggested)
>
> My preference is the first approach for a couple of
> reasons:
> - it forces a strict separation. Tapestry core
> never directly constructs
> javascript so there is no chance it will use
> functions/etc from a
> particular
> library
> - it means that there can be a lot more freedom on
> how the javascript is
> written. e.g. field validations could be
> accumulated & written out as a
> JSON data type, added directly to elements via
> css/custom attributes or
> accumulated via function calls (as is done
> presently).
> - tapestry core makes no assumptions about the
> client side environment. I
>
> can see this being a benefit when dealing with other
> platforms such as
> mobile phones.
>
> On the downside it may be harder to construct a good
> java api that covers
> all the possibilities. However that is no reason not
> to try! :)
>
>
> cheers
> Ben
>
>
> > -----Original Message-----
> > From: Andreas Andreou [mailto:andreoua@gmail.com]
> On Behalf Of andyhot
> > Sent: Wednesday, 3 October 2007 1:58 PM
> > To: Tapestry development
> > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs.
> ???
> >
> > I think you're misunderstanding my intentions :)
> >
> > Here are the facts the way i see them:
> > - Tapestry needs some js functions for its own
> use, hence tapestry.js
> > - I do NOT want to force users (not even myself)
> to go through
> > tapestry.js - they should be able to
> > use the library they want to
> > - I do NOT want to force users to have to load
> another library simply
> > because tapestry.js needs it
> >
> > And here's where i'd be heading at:
> > - Plan js usage in such a way that alternatives to
>
> > tapestry.js (such as
> > tapestry-yui.js or tapestry-jquery.js,
> > or even tapestry-donothing.js) are easy to write
> and even
> > easier to include
> >
> > For the record, i'm close to the
> tapestry-donothing.js step for T4.
> >
> > Joost Schouten wrote:
> > > Hi,
> > >
> > > I see huge potential for build in AJAX with
> tapestry.
> > Component reloading is
> > > something which wasn't too hard to implement.
> But I would
> > not like to be
> > > locked in, or have the framework of choice
> included even if
> > I don't need it
> > > (love your script loading feature btw).
> > >
> > > I am a big fan of making my own choices in this
> area.
> > Martin Reurings
> > > recently posted about this in the user group:
> > >
> >
>
http://www.nabble.com/T5:-using-DOJO--t4368411.html#a12869068
>
> > I strongly
> > > agree and would love to see this kind of
> granularity.
> > Making a tapestry.js
> > > as a wrapper for any framework seems more a
> confinement
> > than an addition.
> > > I'd rather see a clean tapestry module without
> any client
> > side scripting and
> > > potentially one or more modules using the
> framework of choice.
> > >
> > > We already had to do some cutting to have
> Tapestry leave
> > the scripting to
> > > us. I hope Tapestry won't make the same mistake
> a lot of
> > JSF implementations
> > > have made.
> > >
> > > Cheers,
> > > Joost
> > >
> > >
> > > We have just stripped T5 completely of all it's
> javascript
> > as it was causing
> > >
> > >
> > > -----Original Message-----
> > > From: Andreas Andreou
> [mailto:andreoua@gmail.com] On Behalf
> > Of andyhot
> > > Sent: Wednesday, October 03, 2007 2:46 PM
> > > To: Tapestry development
> > > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9
> vs. ???
> > >
> > > In my mind there's only one correct answer for
> Tapestry to this:
> > > nothing and everything!
> > >
> > > ext is looking great these days, yui is ...
> yahoo, dojo
> > 0.9-1.0 is sooo
> > > improved
> > > and prototype is ... the good old prototype -
> and who knows
> > what's to come
> > >
> > > If anyone's been looking at my recent 4.1
> commits, i've set
> > to abstract
> > > all dojo calls through
> > > the tapestry object - and i've been able to do
> this by
> > introducing just
> > > 6-7 more functions in it.
> > > And i can now replace dojo with other libraries
> - i expect
> > a few more
> > > technical challenges, but
> > > it should be straightforward to work
> > >
> > > So, perhaps this would prove as a guide for T5
> as well
> > >
> > >
> > > Howard Lewis Ship wrote:
> > >
> > >> I've been having some fun wrapping my brain
> around JQuery.
> > >>
> > >> I'm not fully certain its a great fit however.
> > >>
> > >> For hand-tooled web pages, maybe traditional
> JSPs, it
> > would be perfectly
> > >> good.
> > >>
> > >> But it's really built around identifying
> elements that
>
=== message truncated ===
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Ben Sommerville <be...@bulletproof.com.au>.
I've been mulling on this topic for a while since I'm working
(intermittently)
on a project that uses JQuery & Tap5.
I would love it if Tapestry core was not coupled to any particular
javascript
library & could also be used without any javascript at all.
Obviously to do this we'd need to introduce an abstraction/indirection
layer
for the parts of tapestry that may use javascript. The two approaches I
see
are:
a) Define a java api for invoking/using/generating javascript that
Tapestry
core uses, then create modules for each javascript library
(as Joost suggested)
b) Define an javascript api that Tapestry invokes then create
implementations
of that for various javascript libraries
(as Andreas suggested)
My preference is the first approach for a couple of reasons:
- it forces a strict separation. Tapestry core never directly constructs
javascript so there is no chance it will use functions/etc from a
particular
library
- it means that there can be a lot more freedom on how the javascript is
written. e.g. field validations could be accumulated & written out as a
JSON data type, added directly to elements via css/custom attributes or
accumulated via function calls (as is done presently).
- tapestry core makes no assumptions about the client side environment. I
can see this being a benefit when dealing with other platforms such as
mobile phones.
On the downside it may be harder to construct a good java api that covers
all the possibilities. However that is no reason not to try! :)
cheers
Ben
> -----Original Message-----
> From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf Of andyhot
> Sent: Wednesday, 3 October 2007 1:58 PM
> To: Tapestry development
> Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
>
> I think you're misunderstanding my intentions :)
>
> Here are the facts the way i see them:
> - Tapestry needs some js functions for its own use, hence tapestry.js
> - I do NOT want to force users (not even myself) to go through
> tapestry.js - they should be able to
> use the library they want to
> - I do NOT want to force users to have to load another library simply
> because tapestry.js needs it
>
> And here's where i'd be heading at:
> - Plan js usage in such a way that alternatives to
> tapestry.js (such as
> tapestry-yui.js or tapestry-jquery.js,
> or even tapestry-donothing.js) are easy to write and even
> easier to include
>
> For the record, i'm close to the tapestry-donothing.js step for T4.
>
> Joost Schouten wrote:
> > Hi,
> >
> > I see huge potential for build in AJAX with tapestry.
> Component reloading is
> > something which wasn't too hard to implement. But I would
> not like to be
> > locked in, or have the framework of choice included even if
> I don't need it
> > (love your script loading feature btw).
> >
> > I am a big fan of making my own choices in this area.
> Martin Reurings
> > recently posted about this in the user group:
> >
> http://www.nabble.com/T5:-using-DOJO--t4368411.html#a12869068
> I strongly
> > agree and would love to see this kind of granularity.
> Making a tapestry.js
> > as a wrapper for any framework seems more a confinement
> than an addition.
> > I'd rather see a clean tapestry module without any client
> side scripting and
> > potentially one or more modules using the framework of choice.
> >
> > We already had to do some cutting to have Tapestry leave
> the scripting to
> > us. I hope Tapestry won't make the same mistake a lot of
> JSF implementations
> > have made.
> >
> > Cheers,
> > Joost
> >
> >
> > We have just stripped T5 completely of all it's javascript
> as it was causing
> >
> >
> > -----Original Message-----
> > From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf
> Of andyhot
> > Sent: Wednesday, October 03, 2007 2:46 PM
> > To: Tapestry development
> > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
> >
> > In my mind there's only one correct answer for Tapestry to this:
> > nothing and everything!
> >
> > ext is looking great these days, yui is ... yahoo, dojo
> 0.9-1.0 is sooo
> > improved
> > and prototype is ... the good old prototype - and who knows
> what's to come
> >
> > If anyone's been looking at my recent 4.1 commits, i've set
> to abstract
> > all dojo calls through
> > the tapestry object - and i've been able to do this by
> introducing just
> > 6-7 more functions in it.
> > And i can now replace dojo with other libraries - i expect
> a few more
> > technical challenges, but
> > it should be straightforward to work
> >
> > So, perhaps this would prove as a guide for T5 as well
> >
> >
> > Howard Lewis Ship wrote:
> >
> >> I've been having some fun wrapping my brain around JQuery.
> >>
> >> I'm not fully certain its a great fit however.
> >>
> >> For hand-tooled web pages, maybe traditional JSPs, it
> would be perfectly
> >> good.
> >>
> >> But it's really built around identifying elements that
> need "special
> >> attention" in terms of CSS class and page structure, and
> then applying
> >> uniform effects and logic (in the form of even handlers) to them.
> >>
> >> Tapestry is more geared towards the server side "seeding"
> the client side
> >> with specific element ids, and then hooking up the
> appropriate event
> >>
> > handler
> >
> >> that way.
> >>
> >> In fact, that is more Protoype's angle, the whole point of
> $("myid") being
> >> so easy. JQuery lets you use Document.getElementById()
> ... it's one area
> >> where the $() function has no great magic.
> >>
> >> Can Tapestry shift? Should it? Would the newly revised
> Dojo be a better
> >> fit?
> >>
> >>
> >>
> >
> >
>
> --
> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> Tapestry / Tacos developer
> Open Source / JEE Consulting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by andyhot <an...@di.uoa.gr>.
I think you're misunderstanding my intentions :)
Here are the facts the way i see them:
- Tapestry needs some js functions for its own use, hence tapestry.js
- I do NOT want to force users (not even myself) to go through
tapestry.js - they should be able to
use the library they want to
- I do NOT want to force users to have to load another library simply
because tapestry.js needs it
And here's where i'd be heading at:
- Plan js usage in such a way that alternatives to tapestry.js (such as
tapestry-yui.js or tapestry-jquery.js,
or even tapestry-donothing.js) are easy to write and even easier to include
For the record, i'm close to the tapestry-donothing.js step for T4.
Joost Schouten wrote:
> Hi,
>
> I see huge potential for build in AJAX with tapestry. Component reloading is
> something which wasn't too hard to implement. But I would not like to be
> locked in, or have the framework of choice included even if I don't need it
> (love your script loading feature btw).
>
> I am a big fan of making my own choices in this area. Martin Reurings
> recently posted about this in the user group:
> http://www.nabble.com/T5:-using-DOJO--t4368411.html#a12869068 I strongly
> agree and would love to see this kind of granularity. Making a tapestry.js
> as a wrapper for any framework seems more a confinement than an addition.
> I'd rather see a clean tapestry module without any client side scripting and
> potentially one or more modules using the framework of choice.
>
> We already had to do some cutting to have Tapestry leave the scripting to
> us. I hope Tapestry won't make the same mistake a lot of JSF implementations
> have made.
>
> Cheers,
> Joost
>
>
> We have just stripped T5 completely of all it's javascript as it was causing
>
>
> -----Original Message-----
> From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf Of andyhot
> Sent: Wednesday, October 03, 2007 2:46 PM
> To: Tapestry development
> Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
>
> In my mind there's only one correct answer for Tapestry to this:
> nothing and everything!
>
> ext is looking great these days, yui is ... yahoo, dojo 0.9-1.0 is sooo
> improved
> and prototype is ... the good old prototype - and who knows what's to come
>
> If anyone's been looking at my recent 4.1 commits, i've set to abstract
> all dojo calls through
> the tapestry object - and i've been able to do this by introducing just
> 6-7 more functions in it.
> And i can now replace dojo with other libraries - i expect a few more
> technical challenges, but
> it should be straightforward to work
>
> So, perhaps this would prove as a guide for T5 as well
>
>
> Howard Lewis Ship wrote:
>
>> I've been having some fun wrapping my brain around JQuery.
>>
>> I'm not fully certain its a great fit however.
>>
>> For hand-tooled web pages, maybe traditional JSPs, it would be perfectly
>> good.
>>
>> But it's really built around identifying elements that need "special
>> attention" in terms of CSS class and page structure, and then applying
>> uniform effects and logic (in the form of even handlers) to them.
>>
>> Tapestry is more geared towards the server side "seeding" the client side
>> with specific element ids, and then hooking up the appropriate event
>>
> handler
>
>> that way.
>>
>> In fact, that is more Protoype's angle, the whole point of $("myid") being
>> so easy. JQuery lets you use Document.getElementById() ... it's one area
>> where the $() function has no great magic.
>>
>> Can Tapestry shift? Should it? Would the newly revised Dojo be a better
>> fit?
>>
>>
>>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Joost Schouten <jo...@jsportal.com>.
Hi,
I see huge potential for build in AJAX with tapestry. Component reloading is
something which wasn't too hard to implement. But I would not like to be
locked in, or have the framework of choice included even if I don't need it
(love your script loading feature btw).
I am a big fan of making my own choices in this area. Martin Reurings
recently posted about this in the user group:
http://www.nabble.com/T5:-using-DOJO--t4368411.html#a12869068 I strongly
agree and would love to see this kind of granularity. Making a tapestry.js
as a wrapper for any framework seems more a confinement than an addition.
I'd rather see a clean tapestry module without any client side scripting and
potentially one or more modules using the framework of choice.
We already had to do some cutting to have Tapestry leave the scripting to
us. I hope Tapestry won't make the same mistake a lot of JSF implementations
have made.
Cheers,
Joost
We have just stripped T5 completely of all it's javascript as it was causing
-----Original Message-----
From: Andreas Andreou [mailto:andreoua@gmail.com] On Behalf Of andyhot
Sent: Wednesday, October 03, 2007 2:46 PM
To: Tapestry development
Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
In my mind there's only one correct answer for Tapestry to this:
nothing and everything!
ext is looking great these days, yui is ... yahoo, dojo 0.9-1.0 is sooo
improved
and prototype is ... the good old prototype - and who knows what's to come
If anyone's been looking at my recent 4.1 commits, i've set to abstract
all dojo calls through
the tapestry object - and i've been able to do this by introducing just
6-7 more functions in it.
And i can now replace dojo with other libraries - i expect a few more
technical challenges, but
it should be straightforward to work
So, perhaps this would prove as a guide for T5 as well
Howard Lewis Ship wrote:
> I've been having some fun wrapping my brain around JQuery.
>
> I'm not fully certain its a great fit however.
>
> For hand-tooled web pages, maybe traditional JSPs, it would be perfectly
> good.
>
> But it's really built around identifying elements that need "special
> attention" in terms of CSS class and page structure, and then applying
> uniform effects and logic (in the form of even handlers) to them.
>
> Tapestry is more geared towards the server side "seeding" the client side
> with specific element ids, and then hooking up the appropriate event
handler
> that way.
>
> In fact, that is more Protoype's angle, the whole point of $("myid") being
> so easy. JQuery lets you use Document.getElementById() ... it's one area
> where the $() function has no great magic.
>
> Can Tapestry shift? Should it? Would the newly revised Dojo be a better
> fit?
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by liigo <co...@gmail.com>.
2007/10/3, andyhot <an...@di.uoa.gr>:
>
> If anyone's been looking at my recent 4.1 commits, i've set to abstract
> all dojo calls through
> the tapestry object - and i've been able to do this by introducing just
> 6-7 more functions in it.
gook work. and we can doing this in T5 and wraps jquery as default?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by andyhot <an...@di.uoa.gr>.
In my mind there's only one correct answer for Tapestry to this:
nothing and everything!
ext is looking great these days, yui is ... yahoo, dojo 0.9-1.0 is sooo
improved
and prototype is ... the good old prototype - and who knows what's to come
If anyone's been looking at my recent 4.1 commits, i've set to abstract
all dojo calls through
the tapestry object - and i've been able to do this by introducing just
6-7 more functions in it.
And i can now replace dojo with other libraries - i expect a few more
technical challenges, but
it should be straightforward to work
So, perhaps this would prove as a guide for T5 as well
Howard Lewis Ship wrote:
> I've been having some fun wrapping my brain around JQuery.
>
> I'm not fully certain its a great fit however.
>
> For hand-tooled web pages, maybe traditional JSPs, it would be perfectly
> good.
>
> But it's really built around identifying elements that need "special
> attention" in terms of CSS class and page structure, and then applying
> uniform effects and logic (in the form of even handlers) to them.
>
> Tapestry is more geared towards the server side "seeding" the client side
> with specific element ids, and then hooking up the appropriate event handler
> that way.
>
> In fact, that is more Protoype's angle, the whole point of $("myid") being
> so easy. JQuery lets you use Document.getElementById() ... it's one area
> where the $() function has no great magic.
>
> Can Tapestry shift? Should it? Would the newly revised Dojo be a better
> fit?
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I don't have much to sway the conversation, but I wanted to maybe widen
your horizons and mention Facebook Javascript (FBJS) as well. A
facebook application can use javascript, but it is sandboxed through
rewriting, etc, so as to prevent full access to the browser from 3rd
party applications. That means that not all javascript functionality is
allowed, and you have to use their special objects for Ajax operations, etc.
http://wiki.developers.facebook.com/index.php/FBJS
At the moment I can't use any of the T5 forms, etc, because it uses
prototype and higher end javascript not supported by FBJS. I really
liked the idea that someone mentioned earlier of being able to cajole T5
into using much simpler javascript - that could work under FBJS.
just my 2 cents.
fernando
Jesse Kuhnert wrote:
> Yeah no I wouldn't go quite that far...
>
> It seems like Tapestry could really have its own extremely tight/small
> library for the very basic of dom manipulations / css selectors /
> event handling that is independent of any particular library...I think
> dean edwards has a nice version of this - you could probably just lift
> whatever functions are needed from him:
>
> http://code.google.com/p/base2/
>
> When it comes time to plug in jquery / prototype / dojo / whatever
> that'll be a different beast to tackle. No idea how it should be
> done but it does feel like you'd need to do something ejb3 persistence
> -like where you have a standard set of annotations / behaviors that
> can handle the very basic of things - which will probably be few since
> each works so differently...
>
> Then - you can have specific annotations / mixins / etc for each
> library. (such as how hibernate still has hibernate specific things
> you can do that don't fit in to the ejb3 persistence spec) The way
> each library handles xhr and how you interact with results are all
> slightly different and it would seem to break the idea of experiencing
> the unique benefits of each one by trying to force one rigid coding
> style on everyone...
>
> Probably the only way to realistically get this right is provide
> support for two different libraries right from the start so that no
> naughty API parts are left out for too long that would need to be
> fixed when you realize what has to happen with multiple libraries.
>
> I'm not at all happy with how T4 handles a lot of this stuff currently
> - so I wouldn't look at it ~too~ closely. ...T5 seems to offer the
> promise of a much cleaner / intuitive API with all of the mixin /
> annotation / etc goodness lurking around.
>
> in the end though - jQuery has the most potential good to offer
> (imho..for now) since John now works at mozilla and sort of gets
> influenced by the javascript gods directly.
>
> It's going to be a huge PITA to get right, maybe a branch would help?
> My fingers are getting very itchy to work on T5 so maybe if Howard
> starts to scratch out some of the initial stuff we can come in
> afterwards and try to add in prototype support or something else like
> that? dunno...
>
> On 10/3/07, andyhot <an...@di.uoa.gr> wrote:
>> That's the general idea -
>> thought (imho) such bodies are usually slow to react on changes, new
>> features, e.t.c.
>>
>> I remember talking about this with jesse a year ago... and it hasnt
>> really taken off
>>
>>
>>
>> Markus Joschko wrote:
>>> What about the openajax hub (http://www.openajax.org/OpenAjax%20Hub.html)?
>>>
>>> As this is some kind of minimal standard that should work with every library.
>>> E.g. on a form submit the tapestry.js can simply submit an event that
>>> gives the id of the form that should be submitted and every javascript
>>> library that's interested in validating and sending the form can
>>> listen to that event.
>>>
>>> Markus
>>>
>>>
>>> On 10/3/07, jblier <ja...@airwidesolutions.com> wrote:
>>>
>>>> I still prefer Prototype although JQuery is improving at a quick pace.
>>>>
>>>> I don't like Dojo because it needs a lot of special tags.
>>>>
>>>> In any event, the developer should be able to use any JS library or
>>>> framework he would like.
>>>>
>>>> Is is possible to have Tapestry.js modified to be a wrapper that would be
>>>> compatible with a small list of JS libraries? So if a developer chooses a
>>>> library from the list, Tapestry won't need to be rewritten.
>>>> --
>>>> View this message in context: http://www.nabble.com/Prototype-vs.-JQuery-vs.-Dojo-0.9-vs.-----tf4559353.html#a13022582
>>>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>>
>> --
>> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
>> Tapestry / Tacos developer
>> Open Source / JEE Consulting
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah no I wouldn't go quite that far...
It seems like Tapestry could really have its own extremely tight/small
library for the very basic of dom manipulations / css selectors /
event handling that is independent of any particular library...I think
dean edwards has a nice version of this - you could probably just lift
whatever functions are needed from him:
http://code.google.com/p/base2/
When it comes time to plug in jquery / prototype / dojo / whatever
that'll be a different beast to tackle. No idea how it should be
done but it does feel like you'd need to do something ejb3 persistence
-like where you have a standard set of annotations / behaviors that
can handle the very basic of things - which will probably be few since
each works so differently...
Then - you can have specific annotations / mixins / etc for each
library. (such as how hibernate still has hibernate specific things
you can do that don't fit in to the ejb3 persistence spec) The way
each library handles xhr and how you interact with results are all
slightly different and it would seem to break the idea of experiencing
the unique benefits of each one by trying to force one rigid coding
style on everyone...
Probably the only way to realistically get this right is provide
support for two different libraries right from the start so that no
naughty API parts are left out for too long that would need to be
fixed when you realize what has to happen with multiple libraries.
I'm not at all happy with how T4 handles a lot of this stuff currently
- so I wouldn't look at it ~too~ closely. ...T5 seems to offer the
promise of a much cleaner / intuitive API with all of the mixin /
annotation / etc goodness lurking around.
in the end though - jQuery has the most potential good to offer
(imho..for now) since John now works at mozilla and sort of gets
influenced by the javascript gods directly.
It's going to be a huge PITA to get right, maybe a branch would help?
My fingers are getting very itchy to work on T5 so maybe if Howard
starts to scratch out some of the initial stuff we can come in
afterwards and try to add in prototype support or something else like
that? dunno...
On 10/3/07, andyhot <an...@di.uoa.gr> wrote:
> That's the general idea -
> thought (imho) such bodies are usually slow to react on changes, new
> features, e.t.c.
>
> I remember talking about this with jesse a year ago... and it hasnt
> really taken off
>
>
>
> Markus Joschko wrote:
> > What about the openajax hub (http://www.openajax.org/OpenAjax%20Hub.html)?
> >
> > As this is some kind of minimal standard that should work with every library.
> > E.g. on a form submit the tapestry.js can simply submit an event that
> > gives the id of the form that should be submitted and every javascript
> > library that's interested in validating and sending the form can
> > listen to that event.
> >
> > Markus
> >
> >
> > On 10/3/07, jblier <ja...@airwidesolutions.com> wrote:
> >
> >> I still prefer Prototype although JQuery is improving at a quick pace.
> >>
> >> I don't like Dojo because it needs a lot of special tags.
> >>
> >> In any event, the developer should be able to use any JS library or
> >> framework he would like.
> >>
> >> Is is possible to have Tapestry.js modified to be a wrapper that would be
> >> compatible with a small list of JS libraries? So if a developer chooses a
> >> library from the list, Tapestry won't need to be rewritten.
> >> --
> >> View this message in context: http://www.nabble.com/Prototype-vs.-JQuery-vs.-Dojo-0.9-vs.-----tf4559353.html#a13022582
> >> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
> >
>
> --
> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> Tapestry / Tacos developer
> Open Source / JEE Consulting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by andyhot <an...@di.uoa.gr>.
That's the general idea -
thought (imho) such bodies are usually slow to react on changes, new
features, e.t.c.
I remember talking about this with jesse a year ago... and it hasnt
really taken off
Markus Joschko wrote:
> What about the openajax hub (http://www.openajax.org/OpenAjax%20Hub.html)?
>
> As this is some kind of minimal standard that should work with every library.
> E.g. on a form submit the tapestry.js can simply submit an event that
> gives the id of the form that should be submitted and every javascript
> library that's interested in validating and sending the form can
> listen to that event.
>
> Markus
>
>
> On 10/3/07, jblier <ja...@airwidesolutions.com> wrote:
>
>> I still prefer Prototype although JQuery is improving at a quick pace.
>>
>> I don't like Dojo because it needs a lot of special tags.
>>
>> In any event, the developer should be able to use any JS library or
>> framework he would like.
>>
>> Is is possible to have Tapestry.js modified to be a wrapper that would be
>> compatible with a small list of JS libraries? So if a developer chooses a
>> library from the list, Tapestry won't need to be rewritten.
>> --
>> View this message in context: http://www.nabble.com/Prototype-vs.-JQuery-vs.-Dojo-0.9-vs.-----tf4559353.html#a13022582
>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Markus Joschko <ma...@gmail.com>.
What about the openajax hub (http://www.openajax.org/OpenAjax%20Hub.html)?
As this is some kind of minimal standard that should work with every library.
E.g. on a form submit the tapestry.js can simply submit an event that
gives the id of the form that should be submitted and every javascript
library that's interested in validating and sending the form can
listen to that event.
Markus
On 10/3/07, jblier <ja...@airwidesolutions.com> wrote:
>
> I still prefer Prototype although JQuery is improving at a quick pace.
>
> I don't like Dojo because it needs a lot of special tags.
>
> In any event, the developer should be able to use any JS library or
> framework he would like.
>
> Is is possible to have Tapestry.js modified to be a wrapper that would be
> compatible with a small list of JS libraries? So if a developer chooses a
> library from the list, Tapestry won't need to be rewritten.
> --
> View this message in context: http://www.nabble.com/Prototype-vs.-JQuery-vs.-Dojo-0.9-vs.-----tf4559353.html#a13022582
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by jblier <ja...@airwidesolutions.com>.
I still prefer Prototype although JQuery is improving at a quick pace.
I don't like Dojo because it needs a lot of special tags.
In any event, the developer should be able to use any JS library or
framework he would like.
Is is possible to have Tapestry.js modified to be a wrapper that would be
compatible with a small list of JS libraries? So if a developer chooses a
library from the list, Tapestry won't need to be rewritten.
--
View this message in context: http://www.nabble.com/Prototype-vs.-JQuery-vs.-Dojo-0.9-vs.-----tf4559353.html#a13022582
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Posted by Jesse Kuhnert <jk...@gmail.com>.
I think forcing anyone to pick one library is a mistake.
On 10/2/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been having some fun wrapping my brain around JQuery.
>
> I'm not fully certain its a great fit however.
>
> For hand-tooled web pages, maybe traditional JSPs, it would be perfectly
> good.
>
> But it's really built around identifying elements that need "special
> attention" in terms of CSS class and page structure, and then applying
> uniform effects and logic (in the form of even handlers) to them.
>
> Tapestry is more geared towards the server side "seeding" the client side
> with specific element ids, and then hooking up the appropriate event handler
> that way.
>
> In fact, that is more Protoype's angle, the whole point of $("myid") being
> so easy. JQuery lets you use Document.getElementById() ... it's one area
> where the $() function has no great magic.
>
> Can Tapestry shift? Should it? Would the newly revised Dojo be a better
> fit?
>
> --
> Howard M. Lewis Ship
> Partner and Senior Architect at Feature50
>
> Creator Apache Tapestry and Apache HiveMind
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org