tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davor Hrg" <hrgda...@gmail.com>
Subject Re: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
Date Wed, 03 Oct 2007 06:29:39 GMT
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 <ben@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message