You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by ice <fr...@gmail.com> on 2009/06/10 13:02:08 UTC
Re: Switch from Prototype to jQuery?
Standing from the point of view that i prefer jQuery to prototype, i would
like to see (Tapestry 5.2? ) a move into breaking down what the core web
functionalities, from those that depend on Javascript, particularly any
extensions, such as Prototype. But plain switching to jQuery is even worse.
A web framework shouldn't be tied to specific javascript/effects library
such as Prototype+Script.aculo.us
By extracting out all the components that rely heavily on dynamic javascript
behaviour into its own module, you divide and conquer. With a small layer of
abstraction on the core functionalities when needed, and on top of it, allow
people to use the javascript framework of their choice, and encourage more
people to actually add support.
Davor Hrg wrote:
>
> Tapestry core can benefit from using less library code as possible.Use few
> utility functions from the days crossbrowser libraries just started,
> and those that are not too much to implement.
>
>
> high level stuff from jquery protoype dojo yui etc. are all different in
> the
> approach.
>
> a list should be made what utilities are of essence for tapestry js.
> some tapestry functions that use library a lot but solve a specific
> problem
> could be left for plugin lib to reimplement.
>
> a good point to start would be removing this prototype centric stuff I
> mentioned,
> element.getFieldEventManager()
> with something like:
> Tapestry.getFieldEventManager(element)
>
> although changing the prototype of the Function class and adding the bind
> to it no big deal you might consider changing the code like this:
> this.repositionBubble.bind(this)
> to
> Tapestry.bind(this.repositionBubble,this);
>
> it is longer, and bit uglier but more neutral I guess.
>
>
> One may think this is pretty:
> this.form.getElements().each(function(element)
> {
> var fem = $T(element).fieldEventManager;
>
> if (fem != undefined)
> {
> // Ask the FEM to validate input for the field, which
> fires
> // a number of events.
> var error = fem.validateInput();
>
> if (error && ! firstErrorField)
> {
> firstErrorField = element;
> }
> }
> });
>
> but why not just replace the first line with:
> var elems = Tapestry.form.getElements(this.form);
> for(element in elems)
>
>
> The impl of the func would be obviously
> Tapestry.form.getElements = function(form){return form.getElements();}
>
>
> Davor Hrg
>
>
>
> On Thu, Feb 12, 2009 at 1:27 AM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
>> These are all good points. When this last flared up, at least a year
>> back, I didn't want to tackle it because I could not then say what the
>> "minimal set of functionality" would be. I think we're closer now.
>> Coding in such a way that we can easily swap out or mix-n-match
>> Prototype and jQuery will make people very happy.
>>
>> On Wed, Feb 11, 2009 at 2:07 PM, Davor Hrg <hr...@gmail.com> wrote:
>> > One small example from tapestry.js
>> > when looking at this as prototype centric app
>> > it is totaly ok, but from the angle of enabling other libs this
>> approach
>> > is completely unnecessary and easily fixed.
>> >
>> > again this is one example (rewriting all may not be as easy)..
>> >
>> > this code is called (tapestry.js:551)
>> > Element.addMethods(['INPUT', 'SELECT', 'TEXTAREA'],
>> > ...
>> > getFieldEventManager : function(field)
>> > ...
>> >
>> > searching whole source for tapestry core reveals that this function is
>> only
>> > used in tapestry.js
>> >
>> > tapestry.js:588
>> > element.getFieldEventManager().showValidationMessage(message);
>> >
>> > the code can easily be rewriten to use
>> >
>> > Tapestry.getFieldEventManager(element).showValidationMessage(message);
>> >
>> > this removes need for prototype and extending dome nodes for this
>> example
>> >
>> > You can argue that other projects might rely on tapestry doing things
>> like
>> > this,
>> > but an compatible version for prototype can be left like this and
>> version
>> > for other libs
>> > with the new approach (the other libs don't like prototype.js anyway).
>> This
>> > can mean
>> > that people with other js libs are fixed to tapestry core only but this
>> I
>> > suppose is ok for many....
>> >
>> >
>> > Davor Hrg
>> >
>> >
>> >
>> >
>> > On Wed, Feb 11, 2009 at 10:14 PM, Davor Hrg <hr...@gmail.com> wrote:
>> >
>> >> I was even willing to do this wrapper thing almost a year ago,all this
>> is
>> >> from going through tapestry js code last spring....
>> >> some things are just thoughts on what should not be done, and some may
>> be
>> >> comments on tap.js ....
>> >>
>> >> the Tapestry js code is not so complicated,
>> >> and uses only a portion of prototype
>> >>
>> >> there can even be something like prototype slimmed for it to work as
>> well.
>> >>
>> >> the components are not remotely close in complexity to any framework
>> >> even prototype is overkill for tapestry.
>> >>
>> >> It definitely extensively used Function.bind which is a five-liner and
>> >> is similar dojo.hitch, it also uses $ function which is a simple as
>> well
>> >>
>> >> It should avoid prototype specific approach of expecting dom nodes
>> >> prototypes upgraded and fallback to plain old utility functions
>> >>
>> >> why call :
>> >> $("element").hide()
>> >> when you can as well call (not saying code like this exists in tap.js)
>> :
>> >> Tapestry.hide($('elem'));
>> >> and be more portable
>> >>
>> >> Tapestry core just needs to define a set of minimal js utility
>> functions
>> >> and use prototype for bas on how the funcs should work.
>> >>
>> >> example funcs:
>> >> Tapestry.addClassName
>> >> Tapestry.effect.fadeIn - total light version of js might do no fade
>> and
>> >> just display content
>> >> Tapestry.calcPos - absolute pos for element so a floated one can be
>> aligned
>> >> to it
>> >> some subset of jquery like funcs to more easily find nodes (but search
>> >> only)
>> >> no magic calls to change all nodes properties and shit.
>> >>
>> >> if a submit button can not get context why do crazy stuff in js that
>> is
>> not
>> >> necessary
>> >>
>> >> after that adding/using other js frameworks would be no problem for
>> those
>> >> that like them.
>> >>
>> >> unfortunately I lost a bit of interest after some of my patches not
>> making
>> >> in
>> >> the framework for a long time :(:(
>> >>
>> >> I don't mean to bash on T5, and I do hope I make more time for it in
>> >> following moths.
>> >>
>> >> The blame could be on me as well, a year has almost passed since I
>> looked
>> >> into this, and haven't done much since. :(:(
>> >>
>> >> Davor Hrg
>> >>
>> >>
>> >> On Wed, Feb 4, 2009 at 8:17 AM, Peter Stavrinides <
>> >> P.Stavrinides@albourne.com> wrote:
>> >>
>> >>> >it would be nice if a component could indicate
>> >>> >that the scripts should be at the top for the entire page
>> >>> Vote for this Jira, which requests exactly that:
>> >>> https://issues.apache.org/jira/browse/TAP5-369
>> >>>
>> >>> Peter
>> >>>
>> >>> ----- Original Message -----
>> >>> From: "Joachim Van der Auwera" <jo...@progs.be>
>> >>> To: "Tapestry users" <us...@tapestry.apache.org>
>> >>> Sent: Monday, 2 February, 2009 17:22:06 GMT +02:00 Athens, Beirut,
>> >>> Bucharest, Istanbul
>> >>> Subject: Re: Switch from Prototype to jQuery?
>> >>>
>> >>> I am not so sure.
>> >>>
>> >>> Do all pages/components work the same way if you move the scripts to
>> the
>> >>> top?
>> >>> If that is the case, then it would be nice if a component could
>> indicate
>> >>> that the scripts should be at the top for the entire page.
>> >>> If not, then there is a problem if you want to combine a component
>> which
>> >>> requires scripts at the top with a component which requires scripts
>> at
>> >>> the bottom.
>> >>>
>> >>> Joachim
>> >>>
>> >>> Kevin Menard wrote:
>> >>> > This was an older app that I haven't needed to revisit. At the
>> time,
>> >>> > no such directive existed. If it does, great. Then I guess there
>> >>> > really aren't any problems after all.
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>> --
>> >>> Joachim Van der Auwera
>> >>> PROGS bvba, progs.be
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3054889.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, Jun 10, 2009 at 11:46 AM, Onno Scheffers<on...@piraya.nl> wrote:
> This simply means that particular plugin didn't adhere to the jQuery plugin
> guidelines (http://docs.jquery.com/Plugins/Authoring). A plugin should never
> use $() directly otherwise it will indeed break the jQuery.noConflict
> method. You cannot blame the framework for a faulty plugin.
Thanks for the info! I didn't know that.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Michael Gentry <mg...@masslight.net>.
I don't quite agree with that statement. I started playing around
with T5.1 (mostly having skipped T5.0) and added this line to my
Layout.java component:
@IncludeJavaScriptLibrary
( { "context:js/jquery-1.3.2.min.js",
"context:js/jquery-ui-1.7.1.custom.min.js" } )
The resulting HTML then included not only JQuery, which is what I
wanted, but Prototype and Scriptaculous, which I didn't care about at
all. It adds extra payload to the package even if you don't want to
use it.
mrg
On Wed, Jun 10, 2009 at 10:59 AM, Thiago H. de Paula
Figueiredo<th...@gmail.com> wrote:
> Tapestry is not forcing you to use any Javascript framework, just to
> use jQuery.noConflict() and jQuery() instead of $() when you want ot
> use jQuery.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
> IMHO, the whole Prototype/jQuery compatibility problem is that both
> define a $() function and they work differently, so you can't use code
> based on both of them at the same time without modification. Some time
> ago I used a jQuery color picker in a project. Even using the
> jQuery.noConflict() method, I still needed to replace $() fror
> jQuery() in the color picker code.
This simply means that particular plugin didn't adhere to the jQuery plugin
guidelines (http://docs.jquery.com/Plugins/Authoring). A plugin should never
use $() directly otherwise it will indeed break the jQuery.noConflict
method. You cannot blame the framework for a faulty plugin.
Besides that, the issue is that people want to work with what they know. If
Tapestry can remove the dependency on Prototype, people that want to use
Prototype are free to do so. If they rather use jQuery, they can as well.
If you have to use both (if you are using Chenillekit for example), you'll
have to include both, but then you can only use plugins that are written the
way they should have been written.
Summary: having Prototype and jQuery rely on the same function (the
> same name) both with different functionalities screwed us.
Not really. A jQuery plugin screwed you.
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by Luther Baker <lu...@gmail.com>.
>
> It would be very nice to have Tapestry components be more Javascript
> framework agnostic, but pushing Howard (and the other committers too, they
> exist!, hehehe) to do this and not working on other issues (after all, this
> is all about fixing something that already works, just doesn't work as good
> as we wished) wouldn't be a wise thing to do.
Great thread and I'm really not trying to take away from the momentum - but
per this last idea ... I'd keep in mind that the one of Tapestry's goal is
to increase marketshare.
I'd suggest that, while Javascript agnosticism may not be the top priority
amongst *current* users, I think that in general, it ranks up there (along
with documentation) as being pretty important going forward. It is really
quite an integral part of anything Web 2.0ish.
< $0.02.
-Luther
Re: Switch from Prototype to jQuery?
Posted by Sergey Didenko <se...@gmail.com>.
Ok, I'll move js related discussion there.
> If anyone is interested, I'll be documenting my progress here:
> http://piraya-blog.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 14 Jun 2009 08:57:03 -0300, Onno Scheffers <on...@piraya.nl>
escreveu:
> Are you saying that the component libraries themselves should be able to
> switch between the supported JavaScript frameworks as well?If that's the
> case, there is quite a bit of wrapping-code Tapestry needs to
> introduce/support.
I think so. That's something that was already warned in this thread.
> Also, it'll be a lot of work for those 3rd party library authors to
> rewrite and test against all supported frameworks.
I don't think Howard meant this. A core library has a way larger demand
for being framework-agnostic than a 3rd party one.
> Another problem I see is that 3rd party library authors will want to wrap
> existing framework-specific libraries and widgets that will always map
> directly to the framework they are built for. That's actually one of the
> main reasons for me to use jQuery: The amount of available widgets I
> want to work with in my Tapestry applications.
In this case, the author can use the Tapestry Javascript abstraction layer
or use the no-conflict way of the JS framework. For example, as Onno
pointed out, the jQuery guidelines state that plugins should use jQuery()
instead of $(), preventing conflicts.
> But I think it is more realistic to let the 3rd party libraries dictate
> the JavaScript framework to include. So if you're going to use
> Chenillekit, you are expected to include Prototype JS into your project.
> And if someone creates a Tapestry-wrapper
> for jQuery-UI in the future, you'll have to include jQuery.
I guess that's exatcly what Howard said about the Javascript stack idea.
> Then create a relatively small JavaScript object that is implemented
> differently for Prototype/jQuery/plain. It should only hold the absolute
> minimum amount of low-level functionality Tapestry depends on (like
> firing and listening to events, basic animation, basic
> selector-functionality).
> These Objects act as the JavaScript isolation layer and because they only
> offer low-level functionality the amount of maintenance required on them
> would be low once they are fully working.
I agree 100%. It would be the encapsulation of the abstraction layer in a
single Javascript object. Simple and elegant. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
> At the very least then we need a way to describe the "stack" used by a
> component and guard against incompatibilities, i.e. Protoype needed by
> component A and jquery by component B resulting in a conflict on the $()
> function.
For jQuery it shouldn't really be a problem. The $()-function is only there
to make it easier and quicker to write custom Javascript for end-users.
jQuery allows you to remap its $()-function to something else.
All jQuery-plugins should always use the jQuery()-function instead of the
$()-function. People writing Tapestry components based on jQuery should
adhere to same standard and there won't be any conflicts.
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by Howard Lewis Ship <hl...@gmail.com>.
At the very least then we need a way to describe the "stack" used by a
component and guard against incompatibilities, i.e. Protoype needed by
component A and jquery by component B resulting in a conflict on the $()
function.
On Sun, Jun 14, 2009 at 6:10 AM, Markus Joschko <ma...@gmail.com>wrote:
> I agree with Onno. There is a difference between component libraries
> and the framework itself.
> I want to use the framework without being forced to include some
> specific javascript library. That includes
> basic components like form fields etc.
> I wouldn't mind if more complex components still dictate the library.
> Then I can still decide whether I want to use them or not,
> whether I take the hit of including two libraries in the same page etc.
> However the status quo where even for the "simple things" like form
> validation and basic ajax prototype is required, is very unlucky.
>
> Regards,
> Markus
>
> On Sun, Jun 14, 2009 at 1:57 PM, Onno Scheffers<on...@piraya.nl> wrote:
> >>
> >> In release X (say 5.2) we introduce a more complete Tapestry isolation
> >> layer
> >> and recode Tapestry's internal logic and components to use it. The
> >> isolation layer maps to Prototype and includes parallels to the common
> >> constructs of Prototype used by Tapestry (i.e., $(), observe(), and some
> >> animation). When X is release, we direct 3rd party component developers
> to
> >> release new versions of their libraries that code to the isolation
> layer.
> >
> >
> >
> > Are you saying that the component libraries themselves should be able to
> > switch between the supported JavaScript frameworks as well? If that's the
> > case, there is quite a bit of wrapping-code Tapestry needs to
> > introduce/support. Also, it'll be a lot of work for those 3rd party
> library
> > authors to rewrite and test against all supported frameworks.
> >
> > Another problem I see is that 3rd party library authors will want to wrap
> > existing framework-specific libraries and widgets that will always map
> > directly to the framework they are built for. That's actually one of the
> > main reasons for me to use jQuery: The amount of available widgets I want
> to
> > work with in my Tapestry applications.
> >
> > I think it makes sense for built-in components to talk to the abstraction
> > layer and of course nothing should be stopping 3rd party library creators
> > from doing the same, since it would be very cool. But I think it is more
> > realistic to let the 3rd party libraries dictate the JavaScript framework
> to
> > include. So if you're going to use Chenillekit, you are expected to
> include
> > Prototype JS into your project. And if someone creates a Tapestry-wrapper
> > for jQuery-UI in the future, you'll have to include jQuery.
> >
> > The main reason to still offer some framework-specific support in
> Tapestry
> > would mostly be to save precious client resources: There is no need to
> load
> > up a custom plain JavaScript event-model if the application already
> includes
> > Prototype or jQuery, since they already offer such a model. I also don't
> > think our plain JavaScript code will ever be as fast as the code offered
> by
> > those frameworks.
> >
> > My approach would be to try and keep the public interface of the
> Tapestry.js
> > file largely the same so existing components using it will keep working.
> > Then create a relatively small JavaScript object that is implemented
> > differently for Prototype/jQuery/plain. It should only hold the absolute
> > minimum amount of low-level functionality Tapestry depends on (like
> firing
> > and listening to events, basic animation, basic selector-functionality).
> > These Objects act as the JavaScript isolation layer and because they only
> > offer low-level functionality the amount of maintenance required on them
> > would be low once they are fully working.
> > Tapestry.js should be implemented to use as much plain Javascript as
> > possible and call into the isolation-layer where needed. So instead of
> using
> > the Prototype Hash objects for example, we could be doing the same thing
> > using either plain JavaScript arrays of by creating our own Hash-like
> > object.
> >
> > regards,
> >
> > Onno
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
Re: Switch from Prototype to jQuery?
Posted by Markus Joschko <ma...@gmail.com>.
I agree with Onno. There is a difference between component libraries
and the framework itself.
I want to use the framework without being forced to include some
specific javascript library. That includes
basic components like form fields etc.
I wouldn't mind if more complex components still dictate the library.
Then I can still decide whether I want to use them or not,
whether I take the hit of including two libraries in the same page etc.
However the status quo where even for the "simple things" like form
validation and basic ajax prototype is required, is very unlucky.
Regards,
Markus
On Sun, Jun 14, 2009 at 1:57 PM, Onno Scheffers<on...@piraya.nl> wrote:
>>
>> In release X (say 5.2) we introduce a more complete Tapestry isolation
>> layer
>> and recode Tapestry's internal logic and components to use it. The
>> isolation layer maps to Prototype and includes parallels to the common
>> constructs of Prototype used by Tapestry (i.e., $(), observe(), and some
>> animation). When X is release, we direct 3rd party component developers to
>> release new versions of their libraries that code to the isolation layer.
>
>
>
> Are you saying that the component libraries themselves should be able to
> switch between the supported JavaScript frameworks as well? If that's the
> case, there is quite a bit of wrapping-code Tapestry needs to
> introduce/support. Also, it'll be a lot of work for those 3rd party library
> authors to rewrite and test against all supported frameworks.
>
> Another problem I see is that 3rd party library authors will want to wrap
> existing framework-specific libraries and widgets that will always map
> directly to the framework they are built for. That's actually one of the
> main reasons for me to use jQuery: The amount of available widgets I want to
> work with in my Tapestry applications.
>
> I think it makes sense for built-in components to talk to the abstraction
> layer and of course nothing should be stopping 3rd party library creators
> from doing the same, since it would be very cool. But I think it is more
> realistic to let the 3rd party libraries dictate the JavaScript framework to
> include. So if you're going to use Chenillekit, you are expected to include
> Prototype JS into your project. And if someone creates a Tapestry-wrapper
> for jQuery-UI in the future, you'll have to include jQuery.
>
> The main reason to still offer some framework-specific support in Tapestry
> would mostly be to save precious client resources: There is no need to load
> up a custom plain JavaScript event-model if the application already includes
> Prototype or jQuery, since they already offer such a model. I also don't
> think our plain JavaScript code will ever be as fast as the code offered by
> those frameworks.
>
> My approach would be to try and keep the public interface of the Tapestry.js
> file largely the same so existing components using it will keep working.
> Then create a relatively small JavaScript object that is implemented
> differently for Prototype/jQuery/plain. It should only hold the absolute
> minimum amount of low-level functionality Tapestry depends on (like firing
> and listening to events, basic animation, basic selector-functionality).
> These Objects act as the JavaScript isolation layer and because they only
> offer low-level functionality the amount of maintenance required on them
> would be low once they are fully working.
> Tapestry.js should be implemented to use as much plain Javascript as
> possible and call into the isolation-layer where needed. So instead of using
> the Prototype Hash objects for example, we could be doing the same thing
> using either plain JavaScript arrays of by creating our own Hash-like
> object.
>
> regards,
>
> Onno
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
> In release X (say 5.2) we introduce a more complete Tapestry isolation
> layer
> and recode Tapestry's internal logic and components to use it. The
> isolation layer maps to Prototype and includes parallels to the common
> constructs of Prototype used by Tapestry (i.e., $(), observe(), and some
> animation). When X is release, we direct 3rd party component developers to
> release new versions of their libraries that code to the isolation layer.
Are you saying that the component libraries themselves should be able to
switch between the supported JavaScript frameworks as well? If that's the
case, there is quite a bit of wrapping-code Tapestry needs to
introduce/support. Also, it'll be a lot of work for those 3rd party library
authors to rewrite and test against all supported frameworks.
Another problem I see is that 3rd party library authors will want to wrap
existing framework-specific libraries and widgets that will always map
directly to the framework they are built for. That's actually one of the
main reasons for me to use jQuery: The amount of available widgets I want to
work with in my Tapestry applications.
I think it makes sense for built-in components to talk to the abstraction
layer and of course nothing should be stopping 3rd party library creators
from doing the same, since it would be very cool. But I think it is more
realistic to let the 3rd party libraries dictate the JavaScript framework to
include. So if you're going to use Chenillekit, you are expected to include
Prototype JS into your project. And if someone creates a Tapestry-wrapper
for jQuery-UI in the future, you'll have to include jQuery.
The main reason to still offer some framework-specific support in Tapestry
would mostly be to save precious client resources: There is no need to load
up a custom plain JavaScript event-model if the application already includes
Prototype or jQuery, since they already offer such a model. I also don't
think our plain JavaScript code will ever be as fast as the code offered by
those frameworks.
My approach would be to try and keep the public interface of the Tapestry.js
file largely the same so existing components using it will keep working.
Then create a relatively small JavaScript object that is implemented
differently for Prototype/jQuery/plain. It should only hold the absolute
minimum amount of low-level functionality Tapestry depends on (like firing
and listening to events, basic animation, basic selector-functionality).
These Objects act as the JavaScript isolation layer and because they only
offer low-level functionality the amount of maintenance required on them
would be low once they are fully working.
Tapestry.js should be implemented to use as much plain Javascript as
possible and call into the isolation-layer where needed. So instead of using
the Prototype Hash objects for example, we could be doing the same thing
using either plain JavaScript arrays of by creating our own Hash-like
object.
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by Howard Lewis Ship <hl...@gmail.com>.
I see this as a two stage (two major release) process.
In release X (say 5.2) we introduce a more complete Tapestry isolation layer
and recode Tapestry's internal logic and components to use it. The
isolation layer maps to Prototype and includes parallels to the common
constructs of Prototype used by Tapestry (i.e., $(), observe(), and some
animation). When X is release, we direct 3rd party component developers to
release new versions of their libraries that code to the isolation layer.
Release Y (say 5.3) introduces the logic to select a JavaScript stack.
....
Another option would be a declartive one ... components would include JS but
also declare which "stack" they use, i.e.
@IncludeJavaScriptLibrary("myajaxywidget.js")
@UsesJavascriptStack("jquery")
public class MyAjaxWidget { ... }
Most components would code to the isolation layer; some might only be
functional in one "stack" or another (protoype, jquery, etc.). Tapestry
would detect stack conflicts.
I don't like this option as much.
I'm concerned that any of these approaches will hamstring component
developers, who will have to work with a very reduced JS library (the
isolation layer) in order to please users who want the option to run their
apps using one major stack or the other.
Even worse would be if components had to start including multiple versions
of their JS code to adapt to the active stack.
I think taking some time to really identify the best solution is a good
idea.
I think we'll have the time as I'm focusing on documentation for the
foreseable future.
On Sat, Jun 13, 2009 at 6:51 AM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Sat, 13 Jun 2009 10:45:15 -0300, Onno Scheffers <on...@piraya.nl>
> escreveu:
>
> I tried that first. But the cdata node XML-encodes its content. So
>> Javascript statements like if(a < b) becomes if(a < b). It also didn't
>> seem to render out an actual CDATA block and last but not least: I wanted
>> to make sure the CDATA-line was commented out inside the script-block so
>> browsers won't trip over it.
>>
>
> Ok! :)
>
> At first I called it "Removing Prototype dependencies from Tapestry 5",
>> but the title would then wrap to the next line on most common resolutions.
>> If
>> you can come up with a better title that is no longer than what I have
>> now, I'll change it for you :o)
>>
>
> That's hard, but I'll tell you when I come up with something. :)
>
> Currently I'm reading up on the event-model. A lot of Tapestry-stuff
>> depends on the ability to fire events and respond to it. This is used for
>> things
>> like validation. It is a tricky area that is handled very differently
>> acros different browsers. Both Prototype and jQuery have both implemented
>> their
>> own custom event-model that make using your own events so easy :o)
>>
>
> This may be the trickiest part. Maybe it'll need the definition of some
> framework-indepedent API to bridge the differences between them.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 13 Jun 2009 10:45:15 -0300, Onno Scheffers <on...@piraya.nl>
escreveu:
> I tried that first. But the cdata node XML-encodes its content. So
> Javascript statements like if(a < b) becomes if(a < b). It also didn't
> seem to render out an actual CDATA block and last but not least: I
> wanted to make sure the CDATA-line was commented out inside the
> script-block so
> browsers won't trip over it.
Ok! :)
> At first I called it "Removing Prototype dependencies from Tapestry 5",
> but the title would then wrap to the next line on most common
> resolutions. If
> you can come up with a better title that is no longer than what I have
> now, I'll change it for you :o)
That's hard, but I'll tell you when I come up with something. :)
> Currently I'm reading up on the event-model. A lot of Tapestry-stuff
> depends on the ability to fire events and respond to it. This is used
> for things
> like validation. It is a tricky area that is handled very differently
> acros different browsers. Both Prototype and jQuery have both
> implemented their
> own custom event-model that make using your own events so easy :o)
This may be the trickiest part. Maybe it'll need the definition of some
framework-indepedent API to bridge the differences between them.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
> Just one suggestion: instead of using Element.raw() for adding Javascript
code inside a CDATA section, try using Element.cdata().
I tried that first. But the cdata node XML-encodes its content. So
Javascript statements like if(a < b) becomes if(a < b). It also didn't
seem to render out an actual CDATA block and last but not least: I wanted to
make sure the CDATA-line was commented out inside the script-block so
browsers won't trip over it.
> Another suggestion: instead of "Removing Prototype from Tapestry", what
about "Making Tapestry Javascript-framework independent?". IMHO, the latter
describes more accurately what you're doing. And Tapestry will still work
with Prototype, you're just providing one way of using another framework for
the people who wish that. ;)
At first I called it "Removing Prototype dependencies from Tapestry 5", but
the title would then wrap to the next line on most common resolutions. If
you can come up with a better title that is no longer than what I have now,
I'll change it for you :o)
Currently I'm reading up on the event-model. A lot of Tapestry-stuff depends
on the ability to fire events and respond to it. This is used for things
like validation. It is a tricky area that is handled very differently acros
different browsers. Both Prototype and jQuery have both implemented their
own custom event-model that make using your own events so easy :o)
regards,
Onno
On Sat, Jun 13, 2009 at 2:00 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Sat, 13 Jun 2009 00:30:05 -0300, Angelo Chen <
> angelochen960@yahoo.com.hk> escreveu:
>
> I like what you are doing, keep us posted about your testing project,
>> Prototype free t5 app is something I'm dreaming of:)
>>
>
> Another suggestion: instead of "Removing Prototype from Tapestry", what
> about "Making Tapestry Javascript-framework independent?". IMHO, the latter
> describes more accurately what you're doing. And Tapestry will still work
> with Prototype, you're just providing one way of using another framework for
> the people who wish that. ;)
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 13 Jun 2009 00:30:05 -0300, Angelo Chen
<an...@yahoo.com.hk> escreveu:
> I like what you are doing, keep us posted about your testing project,
> Prototype free t5 app is something I'm dreaming of:)
Another suggestion: instead of "Removing Prototype from Tapestry", what
about "Making Tapestry Javascript-framework independent?". IMHO, the
latter describes more accurately what you're doing. And Tapestry will
still work with Prototype, you're just providing one way of using another
framework for the people who wish that. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Angelo Chen <an...@yahoo.com.hk>.
Hi Onno,
I like what you are doing, keep us posted about your testing project,
Prototype free t5 app is something I'm dreaming of:)
Onno Scheffers-3 wrote:
>
>>
>>
>> Look forward to seeing what you come up with and I hope you enjoy the
>>> challenge!
>>>
>>
>> Me too! :) It's wonderful to know that people want to contribute to the
>> framework we love. ;)
>
>
>
> Thanks guys.
> If anyone is interested, I'll be documenting my progress here:
> http://piraya-blog.blogspot.com
>
> Current status: I have a web-project up and running and I'm able to switch
> between Prototype-mode and Non-prototype-mode (which leaves out the
> prototype libraries).
> $('elementId').activate is now Tapestry.activate('elementId') which means
> the first bit of Prototype-specific code is converted to plain Javascript.
>
> Time to call it a day :)
>
>
> regards,
>
> Onno
>
>
--
View this message in context: http://www.nabble.com/Switch-from-Prototype-to-jQuery--tp21750338p24008860.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 12 Jun 2009 21:09:50 -0300, Onno Scheffers <on...@piraya.nl>
escreveu:
> Thanks guys.
> If anyone is interested, I'll be documenting my progress here:
> http://piraya-blog.blogspot.com
Added to my (long) list of feeds. :)
> Time to call it a day :)
Nice! We have progress! :)
Just one suggestion: instead of using Element.raw() for adding Javascript
code inside a CDATA section, try using Element.cdata().
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
Very interested in following your progress!
Onno Scheffers wrote:
>
> Thanks guys.
> If anyone is interested, I'll be documenting my progress here:
> http://piraya-blog.blogspot.com
>
> Current status: I have a web-project up and running and I'm able to switch
> between Prototype-mode and Non-prototype-mode (which leaves out the
> prototype libraries).
> $('elementId').activate is now Tapestry.activate('elementId') which means
> the first bit of Prototype-specific code is converted to plain Javascript.
>
> Time to call it a day :)
>
>
> regards,
>
> Onno
>
>
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3071898.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
>
> Look forward to seeing what you come up with and I hope you enjoy the
>> challenge!
>>
>
> Me too! :) It's wonderful to know that people want to contribute to the
> framework we love. ;)
Thanks guys.
If anyone is interested, I'll be documenting my progress here:
http://piraya-blog.blogspot.com
Current status: I have a web-project up and running and I'm able to switch
between Prototype-mode and Non-prototype-mode (which leaves out the
prototype libraries).
$('elementId').activate is now Tapestry.activate('elementId') which means
the first bit of Prototype-specific code is converted to plain Javascript.
Time to call it a day :)
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
> Onno, I don't know how good are your javascript skills, but if you
> have some hard problems with jQuery or javascript, you can write me.
>
> I coded some pretty complex javascript stuff in the past. I'm not John
> Resig though :)
Thanks Sergey, that might come in handy!
I'm currently finishing up some other work. Tomorrow and this weekend I'm
going to start my efforts and see if I can wrap my head around the current
implementation.
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by Sergey Didenko <se...@gmail.com>.
Onno, I don't know how good are your javascript skills, but if you
have some hard problems with jQuery or javascript, you can write me.
I coded some pretty complex javascript stuff in the past. I'm not John
Resig though :)
On Thu, Jun 11, 2009 at 2:04 AM, Onno Scheffers<on...@piraya.nl> wrote:
>> 1) Defining an framework-independent API to be used by Tapestry (events,
>> DOM manipulation, selectors, etc). Maybe there's something similar out
>> there, not necessarily Tapestry-related.
>
>
> Sizzle selector (http://sizzlejs.com/) might be a nice contender, but I
> haven't looked into it indepth yet.
>
>
>
>> 2) Reimplement Tapestry.js in other Javascript frameworks (I guess jQuery
>> would get some votes here :)).
>> 3) Reimplement Tapestry components.
>>
>> Another issue would be define a Tapestry-IoC symbol (just like
>> SymbolConstants.PRODUCTION_MODE) to define the default Javascript framework
>> to be used. This way, we could have a single Autocomplete mixin, for
>> example, that looks what JS framework to use and our templates and page
>> classes would be JS framework-independent. But that's the easy part. :)
>
>
>
> I'll dig into the code the next couple of days to get familiar with the way
> things work right now and see what I can do.
>
> regards,
>
> Onno
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
> 1) Defining an framework-independent API to be used by Tapestry (events,
> DOM manipulation, selectors, etc). Maybe there's something similar out
> there, not necessarily Tapestry-related.
Sizzle selector (http://sizzlejs.com/) might be a nice contender, but I
haven't looked into it indepth yet.
> 2) Reimplement Tapestry.js in other Javascript frameworks (I guess jQuery
> would get some votes here :)).
> 3) Reimplement Tapestry components.
>
> Another issue would be define a Tapestry-IoC symbol (just like
> SymbolConstants.PRODUCTION_MODE) to define the default Javascript framework
> to be used. This way, we could have a single Autocomplete mixin, for
> example, that looks what JS framework to use and our templates and page
> classes would be JS framework-independent. But that's the easy part. :)
I'll dig into the code the next couple of days to get familiar with the way
things work right now and see what I can do.
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, Jun 15, 2009 at 12:47 PM, Norman Franke<no...@myasd.com> wrote:
> FWIW, I'm quite happy with Prototype.
Me too!
> I'd vote we use developer cycles for
> something more productive than dealing with library preferences. They are
> largely functionally equivalent and prototype support is already done.
The point here is that the people who want or need Tapestry without
using Prototype are the ones that will write and contribute the code,
not the (current) committers. Open source as its best: the people who
want some feature in a project, instead of just asking for it, will
develop and contribute it. :)
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
> switching js approaches in the middle of the game is definitely an idea
> that needs to be approached with copious amounts of caution and
> consideration.
I think we all agree on that.
And we also all want Tapestry to be the best it can be. Sadly that means
something different to everyone :o)
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 15 Jun 2009 13:06:14 -0300, Piero Sartini <li...@pierosartini.de>
escreveu:
> Maybe we would see way more components for tapestry if they could be
> build with jquery.
They can be built with jQuery. I even made one that I plan to opensource
later. I don't know why other people haven't done components that build on
jQuery.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Piero Sartini <li...@pierosartini.de>.
Am Montag, 15. Juni 2009 17:47:32 schrieb Norman Franke:
> FWIW, I'm quite happy with Prototype. I'd vote we use developer cycles
> for something more productive than dealing with library preferences.
The good news first: Tapestry is opensource. That's why users who see the need
of a jQuery integration are able to jump in and do the work.
The bad news: I don't think they will spend their time on features that are
not on their personal "need" list.
> They are largely functionally equivalent and prototype support is
> already done.
At the core you are able to do the same things. But looking at the available
plugins and third party integrations jQuery is light years ahead. Maybe we
would see way more components for tapestry if they could be build with jquery.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 12 Jun 2009 16:50:44 -0300, Blower, Andy
<An...@proquest.co.uk> escreveu:
> That sounds fine, I would be more bothered if it was to take up a
> massive amount of Howards' time meaning that he had less time to push
> Tapestry forward in other areas.
That's exactly something I was tyring to say but couldn't find how to
write them.
It would be very nice to have Tapestry components be more Javascript
framework agnostic, but pushing Howard (and the other committers too, they
exist!, hehehe) to do this and not working on other issues (after all,
this is all about fixing something that already works, just doesn't work
as good as we wished) wouldn't be a wise thing to do.
> Look forward to seeing what you come up with and I hope you enjoy the
> challenge!
Me too! :) It's wonderful to know that people want to contribute to the
framework we love. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Norman Franke <no...@myasd.com>.
FWIW, I'm quite happy with Prototype. I'd vote we use developer cycles
for something more productive than dealing with library preferences.
They are largely functionally equivalent and prototype support is
already done.
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jun 12, 2009, at 3:50 PM, Blower, Andy wrote:
> That sounds fine, I would be more bothered if it was to take up a
> massive amount of Howards' time meaning that he had less time to
> push Tapestry forward in other areas.
>
> Look forward to seeing what you come up with and I hope you enjoy
> the challenge!
>
>> -----Original Message-----
>> From: Onno Scheffers [mailto:onno@piraya.nl]
>> Sent: 12 June 2009 10:15
>> To: Tapestry users
>> Subject: Re: Switch from Prototype to jQuery?
>>
>> On Thu, Jun 11, 2009 at 11:37 PM, Blower, Andy
>> <An...@proquest.co.uk>wrote:
>>
>>> I'd just like to echo everything Robert said in this message.
>>
>>
>> Hi Andy,
>>
>> don't worry. I've read Roberts message and his concerns are valid.
>> I'm
>> aware
>> this whole thing won't be easy but it's not impossible.
>> Besides, if we keep ignoring the issue entirely, nothing happens. I
>> can
>> at
>> least try and see what I can come up with. Whether it works or not or
>> whether it ever ends up in the Tapestry production release doesn't
>> really
>> matter to me. It's an interesting project to dive into in my spare
>> time
>> :o)
>>
>>
>> regards,
>>
>> Onno
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
RE: Switch from Prototype to jQuery?
Posted by "Blower, Andy" <An...@proquest.co.uk>.
That sounds fine, I would be more bothered if it was to take up a massive amount of Howards' time meaning that he had less time to push Tapestry forward in other areas.
Look forward to seeing what you come up with and I hope you enjoy the challenge!
> -----Original Message-----
> From: Onno Scheffers [mailto:onno@piraya.nl]
> Sent: 12 June 2009 10:15
> To: Tapestry users
> Subject: Re: Switch from Prototype to jQuery?
>
> On Thu, Jun 11, 2009 at 11:37 PM, Blower, Andy
> <An...@proquest.co.uk>wrote:
>
> > I'd just like to echo everything Robert said in this message.
>
>
> Hi Andy,
>
> don't worry. I've read Roberts message and his concerns are valid. I'm
> aware
> this whole thing won't be easy but it's not impossible.
> Besides, if we keep ignoring the issue entirely, nothing happens. I can
> at
> least try and see what I can come up with. Whether it works or not or
> whether it ever ends up in the Tapestry production release doesn't
> really
> matter to me. It's an interesting project to dive into in my spare time
> :o)
>
>
> regards,
>
> Onno
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
On Thu, Jun 11, 2009 at 11:37 PM, Blower, Andy
<An...@proquest.co.uk>wrote:
> I'd just like to echo everything Robert said in this message.
Hi Andy,
don't worry. I've read Roberts message and his concerns are valid. I'm aware
this whole thing won't be easy but it's not impossible.
Besides, if we keep ignoring the issue entirely, nothing happens. I can at
least try and see what I can come up with. Whether it works or not or
whether it ever ends up in the Tapestry production release doesn't really
matter to me. It's an interesting project to dive into in my spare time :o)
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 10 Jun 2009 16:45:53 -0300, Onno Scheffers <on...@piraya.nl>
escreveu:
> I wouldn't mind helping out. I'm not an expert either, so I don't think I
> can do it all alone. But I think this is important enough for the future
> of Tapestry to donate some of my time.
Nice! I think we need to focus in at least three issues:
1) Defining an framework-independent API to be used by Tapestry (events,
DOM manipulation, selectors, etc). Maybe there's something similar out
there, not necessarily Tapestry-related.
2) Reimplement Tapestry.js in other Javascript frameworks (I guess jQuery
would get some votes here :)).
3) Reimplement Tapestry components.
Another issue would be define a Tapestry-IoC symbol (just like
SymbolConstants.PRODUCTION_MODE) to define the default Javascript
framework to be used. This way, we could have a single Autocomplete mixin,
for example, that looks what JS framework to use and our templates and
page classes would be JS framework-independent. But that's the easy part.
:)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
> Does anyone volunteer to write this Javascript encapsulation layer? I think
> it's a nice idea, but I don't have the time nor the Javascript knowledge
> needed.
I wouldn't mind helping out. I'm not an expert either, so I don't think I
can do it all alone. But I think this is important enough for the future of
Tapestry to donate some of my time.
regards,
Onno
RE: Switch from Prototype to jQuery?
Posted by "Blower, Andy" <An...@proquest.co.uk>.
I'd just like to echo everything Robert said in this message.
> -----Original Message-----
> From: robert zeigler [mailto:robert.zeigler@gmail.com] On Behalf Of
> Robert Zeigler
> Sent: 10 June 2009 18:54
> To: Tapestry users
> Subject: Re: Switch from Prototype to jQuery?
>
> I believe it's mentioned in the comments of the previously-referenced
> jira, but, the main reason this issue is trickier than it seems is
> that there are many applications in existence already that are relying
> on:
> 1) The fact that tapestry bundles prototype
> 2) The fact that tapestry relies on prototype.
>
> A trivial example: T5 defines a set of effects (based on the prototype/
> scriptaculous effects) for animating the introduction of content.
> These are reasonable, but there are cases where they aren't quite
> right (such as a slide transition that is too fast or too slow).
> Currently, the only way to work around that is to "monkey-patch"
> tapestry's effect object. But you're now relying on explicit
> knowledge that tapestry is using prototype. Any and every such
> instance would be broken if we were to rewrite tapestry javascript
> handling to use:
> a) a different framework
> b) no framework
> c) an abstracted API with framework-specific implementations.
>
> Prototype may have been the "wrong choice" (something which is more
> opinion than fact), but switching js approaches in the middle of the
> game is definitely an idea that needs to be approached with copious
> amounts of caution and consideration.
>
> Robert
>
> On Jun 10, 2009, at 6/1010:49 AM , Onno Scheffers wrote:
>
> >>
> >> Maybe it doesn't have to be plain js since there's a lot to be
> >> gained from
> >> these libraries. Perhaps all Tapestry's .js files could be moved to
> a
> >> tapestry-prototype module, each of those files could then be
> >> reimplemented
> >> in a tapestry-jquery module.
> >> A problem remains with script snippets written directly from
> >> renderSupport.addScript()
> >> It sounds pretty cumbersome to maintain multiple modules though.
> >
> >
> >
> > The main reason for the plain-Javascript solution is indeed that you
> > will
> > need to support the Javascript files for each and every framework
> > you're
> > going to support in the future. This will make writing new
> > components quite
> > a lot of work as well because you will need to write/update the code
> > for all
> > supported libraries.
> > By sticking to plain Javascript, you don't have that problem.
> >
> > regards,
> >
> > Onno
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
just like in spring, you'll have a separation between the view technologies
and the spring MVC, the classes that represent the web framework should be
in core, and the ui related classes in its own module.
while it can be argued that ui components can change quite a lot, and would
potentially bear the most of the bugs, the core can be more safely
considered internal, and that would help shield the API from changes.
Anyway, I'm happy to have revived this thread because it looks like there's
plenty of room to improve in this area.
Thiago H. de Paula Figueiredo wrote:
>
> Em Wed, 10 Jun 2009 17:16:03 -0300, ice <fr...@gmail.com> escreveu:
>
>> well, that's kind of my idea really. to seperate them into two parts.
>> That way, changes to the UI layer don't break the core.
>
> Changes to the UI layer, as Tapestry is now, won't break the core, so
> there'se no need do separate it in two projects, IMHO. The core is already
> independent of the components.
>
>
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3058500.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 10 Jun 2009 17:16:03 -0300, ice <fr...@gmail.com> escreveu:
> well, that's kind of my idea really. to seperate them into two parts.
> That way, changes to the UI layer don't break the core.
Changes to the UI layer, as Tapestry is now, won't break the core, so
there'se no need do separate it in two projects, IMHO. The core is already
independent of the components.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
Thiago H. de Paula Figueiredo wrote:
>
> Tapestry-core almost donsn't have UI-related code, and all it's all in the
> components and CSS files (that are overridable and can be configured to
> not be used).
>
Thiago H. de Paula Figueiredo wrote:
>
> Tapestry-core has two parts: the framework itself and a set of components.
> The framework isn't dependent on Javascript (including its AJAX support),
> so I think your line is already drawn. Finding the places that use
> Javascript is easy: look for uses of @IncludeJavascriptLibrary and
> RenderSupport.addScript*() methods under the org.apache.tapestry5.corelib
> package.
>
well, that's kind of my idea really. to seperate them into two parts. That
way, changes to the UI layer don't break the core.
The UI module can then start focusing on how to deal with presentation
specific issues, such as Zones and the Tapestry Object.
What do you guys think?
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3058085.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 10 Jun 2009 16:31:55 -0300, ice <fr...@gmail.com> escreveu:
> My point is that Tapestry-core should be about generation of state
> management of pages, and generation of markup. javascript niceties are a
> plus, but not core.
> Moving away UI related code into another module should make it easier to
> encapsulate the problem, and deal with it in a succession of
> refactorings.
Tapestry-core almost donsn't have UI-related code, and all it's all in the
components and CSS files (that are overridable and can be configured to
not be used).
> Once you have the problem isolated, you can consider what to do with the
> javascript framework. Drawing a clear line can be a difficult task, but
> it can help divide responsibilities.
Tapestry-core has two parts: the framework itself and a set of components.
The framework isn't dependent on Javascript (including its AJAX support),
so I think your line is already drawn. Finding the places that use
Javascript is easy: look for uses of @IncludeJavascriptLibrary and
RenderSupport.addScript*() methods under the org.apache.tapestry5.corelib
package.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
My point is that Tapestry-core should be about generation of state management
of pages, and generation of markup. javascript niceties are a plus, but not
core.
Moving away UI related code into another module should make it easier to
encapsulate the problem, and deal with it in a succession of refactorings.
Once you have the problem isolated, you can consider what to do with the
javascript framework. Drawing a clear line can be a difficult task, but it
can help divide responsibilities.
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3057851.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 10 Jun 2009 15:39:56 -0300, ice <fr...@gmail.com> escreveu:
> Even more of a reason to encapsulate as much as possible all this
> patches. Otherwise, as time passes, the API would end up polluted with
> javascript
> patches to support required behaviour.
Does anyone volunteer to write this Javascript encapsulation layer? I
think it's a nice idea, but I don't have the time nor the Javascript
knowledge needed.
> In my view, javascript/css is a very dangerous arena, and deep
> integration can lead you to lock-ins such as this one.
My concept of lock-in is not being able to use an alternative (ActiveX,
for example), so there's no lock-in here, as you can use any Javascript
framework alongside Prototype.
Where do you see CSS deep integration? CSS provides easy overriding of
everything and, in addition, Tapestry provides a configuration symbol to
prevent its CSS file to be included.
> IMHO, tapestry-core should be as javascript free as possible, and another
> module should start to model, in the best possible way, how to deal with
> the UI.
Tapestry-core is not dependent in Prototype nor Javascript itself, some
components are.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
Even more of a reason to encapsulate as much as possible all this patches.
Otherwise, as time passes, the API would end up polluted with javascript
patches to support required behaviour.
In my view, javascript/css is a very dangerous arena, and deep integration
can lead you to lock-ins such as this one.
IMHO, tapestry-core should be as javascript free as possible, and another
module should start to model, in the best possible way, how to deal with the
UI.
I believe it's mentioned in the comments of the previously-referenced
jira, but, the main reason this issue is trickier than it seems is
that there are many applications in existence already that are relying
on:
1) The fact that tapestry bundles prototype
2) The fact that tapestry relies on prototype.
A trivial example: T5 defines a set of effects (based on the prototype/
scriptaculous effects) for animating the introduction of content.
These are reasonable, but there are cases where they aren't quite
right (such as a slide transition that is too fast or too slow).
Currently, the only way to work around that is to "monkey-patch"
tapestry's effect object. But you're now relying on explicit
knowledge that tapestry is using prototype. Any and every such
instance would be broken if we were to rewrite tapestry javascript
handling to use:
a) a different framework
b) no framework
c) an abstracted API with framework-specific implementations.
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3057621.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Robert Zeigler <ro...@scazdl.org>.
I believe it's mentioned in the comments of the previously-referenced
jira, but, the main reason this issue is trickier than it seems is
that there are many applications in existence already that are relying
on:
1) The fact that tapestry bundles prototype
2) The fact that tapestry relies on prototype.
A trivial example: T5 defines a set of effects (based on the prototype/
scriptaculous effects) for animating the introduction of content.
These are reasonable, but there are cases where they aren't quite
right (such as a slide transition that is too fast or too slow).
Currently, the only way to work around that is to "monkey-patch"
tapestry's effect object. But you're now relying on explicit
knowledge that tapestry is using prototype. Any and every such
instance would be broken if we were to rewrite tapestry javascript
handling to use:
a) a different framework
b) no framework
c) an abstracted API with framework-specific implementations.
Prototype may have been the "wrong choice" (something which is more
opinion than fact), but switching js approaches in the middle of the
game is definitely an idea that needs to be approached with copious
amounts of caution and consideration.
Robert
On Jun 10, 2009, at 6/1010:49 AM , Onno Scheffers wrote:
>>
>> Maybe it doesn't have to be plain js since there's a lot to be
>> gained from
>> these libraries. Perhaps all Tapestry's .js files could be moved to a
>> tapestry-prototype module, each of those files could then be
>> reimplemented
>> in a tapestry-jquery module.
>> A problem remains with script snippets written directly from
>> renderSupport.addScript()
>> It sounds pretty cumbersome to maintain multiple modules though.
>
>
>
> The main reason for the plain-Javascript solution is indeed that you
> will
> need to support the Javascript files for each and every framework
> you're
> going to support in the future. This will make writing new
> components quite
> a lot of work as well because you will need to write/update the code
> for all
> supported libraries.
> By sticking to plain Javascript, you don't have that problem.
>
> regards,
>
> Onno
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
> Maybe it doesn't have to be plain js since there's a lot to be gained from
> these libraries. Perhaps all Tapestry's .js files could be moved to a
> tapestry-prototype module, each of those files could then be reimplemented
> in a tapestry-jquery module.
> A problem remains with script snippets written directly from
> renderSupport.addScript()
> It sounds pretty cumbersome to maintain multiple modules though.
The main reason for the plain-Javascript solution is indeed that you will
need to support the Javascript files for each and every framework you're
going to support in the future. This will make writing new components quite
a lot of work as well because you will need to write/update the code for all
supported libraries.
By sticking to plain Javascript, you don't have that problem.
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by Martin Strand <do...@gmail.com>.
On Wed, 10 Jun 2009 17:21:57 +0200, Onno Scheffers <on...@piraya.nl> wrote:
>>
>> The problem is: how would Tapestry do that? Not using any framework?
>> This would mean the committers would need to spend an awful lot of
>> time rewriting something that Javascript frameworks already do. Not
>> only this, but also to cope with the insonsistencies between browsers.
>> Defining an API that could be implemented in Prototype, jQuery or
>> another framework? More viable, but still a lot of work.
>
>
> So far, the most complex parts I've seen that need replacing are the
> onDOMLoaded stuff, the selectors and the AJAX stuff. Everything besides the
> selectors have been done long before the web-frameworks first implemented
> them.
> The selectors (and DOM-traversal) would be the most work to rewrite in plain
> Javascript, unless Tapestry only uses element ids for lookups, I haven't
> checked this yet.
Maybe it doesn't have to be plain js since there's a lot to be gained from these libraries. Perhaps all Tapestry's .js files could be moved to a tapestry-prototype module, each of those files could then be reimplemented in a tapestry-jquery module.
A problem remains with script snippets written directly from renderSupport.addScript()
It sounds pretty cumbersome to maintain multiple modules though.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
> The problem is: how would Tapestry do that? Not using any framework?
> This would mean the committers would need to spend an awful lot of
> time rewriting something that Javascript frameworks already do. Not
> only this, but also to cope with the insonsistencies between browsers.
> Defining an API that could be implemented in Prototype, jQuery or
> another framework? More viable, but still a lot of work.
So far, the most complex parts I've seen that need replacing are the
onDOMLoaded stuff, the selectors and the AJAX stuff. Everything besides the
selectors have been done long before the web-frameworks first implemented
them.
The selectors (and DOM-traversal) would be the most work to rewrite in plain
Javascript, unless Tapestry only uses element ids for lookups, I haven't
checked this yet.
> Tapestry is not forcing you to use any Javascript framework, just to
> use jQuery.noConflict() and jQuery() instead of $() when you want ot
> use jQuery.
Well, like I said before. It sure feels that way.
A lot of Javascript is included into the page (taking up client resources)
and you don't want to force an unnessesary download onto your users. In my
case I'm only using a fraction of what Prototype offers, but the full set of
libraries is included.
I learned Prototype just to be able to create Tapestry components that
blended in, but eventually I moved back to jQuery, simply because of the
enormous amount of great plugins available and to be able to reuse all of
the code I wrote earlier. It still doesn't feel right to me to include so
many Prototype libraries into the pages when so little of it is being used,
especially since Tapestry tries to optimizes everything for performance by
default (GZIP compression, javascript at bottom, etc).
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
excellent resource iberck!
i also like this one mentioned in the blog post:
http://selectors.turnwheel.com/slickspeed.php
jQuery was a clear winner against Prototype in my Ubuntu/Firefox 3 box (287
vs 386)
iberck wrote:
>
>
> Hi, there is a interest survey results of JavaScript Frameworks
>
> http://www.kylehayes.info/2009/03/29/survey-results-javascript-frameworks/
>
> --
> View this message in context:
> http://www.nabble.com/Switch-from-Prototype-to-jQuery--tp21750338p23965054.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3056573.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by iberck <ib...@gmail.com>.
Hi, there is a interest survey results of JavaScript Frameworks
http://www.kylehayes.info/2009/03/29/survey-results-javascript-frameworks/
--
View this message in context: http://www.nabble.com/Switch-from-Prototype-to-jQuery--tp21750338p23965054.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
As a start, anything that deals with Javascript should be moved away from the
core, since it's not essential. a tapestry-ui module would be great starting
point.
When i say forcing, i mean that Prototype is already built-in, rather than
letting me choose which Javascript framework do i want.
Thiago H. de Paula Figueiredo wrote:
>
> On Wed, Jun 10, 2009 at 11:32 AM, ice<fr...@gmail.com> wrote:
>
>> It seems a bit awkward to have a project called tapestry-core that
>> depends
>> in two third-party javascript libraries.
>
> The problem is: how would Tapestry do that? Not using any framework?
> This would mean the committers would need to spend an awful lot of
> time rewriting something that Javascript frameworks already do. Not
> only this, but also to cope with the insonsistencies between browsers.
> Defining an API that could be implemented in Prototype, jQuery or
> another framework? More viable, but still a lot of work.
>
>> It's not just java developers who are affected by using Prototype,but
>> also
>> designers, as it is the case in my project.
>
> Tapestry is not forcing you to use any Javascript framework, just to
> use jQuery.noConflict() and jQuery() instead of $() when you want ot
> use jQuery.
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3056449.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, Jun 10, 2009 at 11:32 AM, ice<fr...@gmail.com> wrote:
> It seems a bit awkward to have a project called tapestry-core that depends
> in two third-party javascript libraries.
The problem is: how would Tapestry do that? Not using any framework?
This would mean the committers would need to spend an awful lot of
time rewriting something that Javascript frameworks already do. Not
only this, but also to cope with the insonsistencies between browsers.
Defining an API that could be implemented in Prototype, jQuery or
another framework? More viable, but still a lot of work.
> It's not just java developers who are affected by using Prototype,but also
> designers, as it is the case in my project.
Tapestry is not forcing you to use any Javascript framework, just to
use jQuery.noConflict() and jQuery() instead of $() when you want ot
use jQuery.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by ice <fr...@gmail.com>.
I voted on the issue in JIRA, since i believe is an important part of
Tapestry that needs to be revisited.
It seems a bit awkward to have a project called tapestry-core that depends
in two third-party javascript libraries.
It's not just java developers who are affected by using Prototype,but also
designers, as it is the case in my project.
I would be very interested to see what are the proposals to move away from
depending in Prototype towards a javascript neutral platform, that allows
for extension.
Angelo Chen wrote:
>
>
> Totally agreed with this, removing dependency is a good step, replacing
> Prototype with jQuery will have the same issue when a better framework
> comes
> in the future. I use jQuery with T5, it works quite well.
>
>
> Onno Scheffers-3 wrote:
>>
>>>
>>> I agree with you. Most T5 users have projects that rely on Prototype
>>> now, so plain switching to jQuery would break backward compatibility.
>>
>>
>>
>> I agree as well. But I don't think there's a need to play the
>> backward-compatibility card here since removing the dependencies doesn't
>> need to break backward compatibility.
>> If Tapestry doesn't depend on any framework at all (just plain
>> Javascript),
>> extensions based on Prototype will still work if the libraries are
>> included
>> into the pages. It just means Tapestry can do without it.
>>
>> It makes the barrier to entry for developers much lower if if the
>> developer
>> can use whatever (s)he's used to. I know you can still use jQuery
>> together
>> with Prototype (that's what I do), but since Prototype is already there,
>> a
>> lot of developers will try and use that because they don't want to force
>> any
>> more js-libraries onto their users than the ones already being included.
>>
>> Learning another javascript framework or even having to rewrite existing
>> Javascript code to another web-framework is time-consuming and
>> error-prone.
>>
>> regards,
>>
>> Onno
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Switch-from-Prototype-to-jQuery--tp21750338p23963427.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3056007.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Angelo Chen <an...@yahoo.com.hk>.
Totally agreed with this, removing dependency is a good step, replacing
Prototype with jQuery will have the same issue when a better framework comes
in the future. I use jQuery with T5, it works quite well.
Onno Scheffers-3 wrote:
>
>>
>> I agree with you. Most T5 users have projects that rely on Prototype
>> now, so plain switching to jQuery would break backward compatibility.
>
>
>
> I agree as well. But I don't think there's a need to play the
> backward-compatibility card here since removing the dependencies doesn't
> need to break backward compatibility.
> If Tapestry doesn't depend on any framework at all (just plain
> Javascript),
> extensions based on Prototype will still work if the libraries are
> included
> into the pages. It just means Tapestry can do without it.
>
> It makes the barrier to entry for developers much lower if if the
> developer
> can use whatever (s)he's used to. I know you can still use jQuery together
> with Prototype (that's what I do), but since Prototype is already there, a
> lot of developers will try and use that because they don't want to force
> any
> more js-libraries onto their users than the ones already being included.
>
> Learning another javascript framework or even having to rewrite existing
> Javascript code to another web-framework is time-consuming and
> error-prone.
>
> regards,
>
> Onno
>
>
--
View this message in context: http://www.nabble.com/Switch-from-Prototype-to-jQuery--tp21750338p23963427.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, Jun 10, 2009 at 11:14 AM, Onno Scheffers<on...@piraya.nl> wrote:
> If Tapestry doesn't depend on any framework at all (just plain Javascript),
> extensions based on Prototype will still work if the libraries are included
> into the pages. It just means Tapestry can do without it.
IMHO, the whole Prototype/jQuery compatibility problem is that both
define a $() function and they work differently, so you can't use code
based on both of them at the same time without modification. Some time
ago I used a jQuery color picker in a project. Even using the
jQuery.noConflict() method, I still needed to replace $() fror
jQuery() in the color picker code. If Tapestry was based on jQuery and
I wanted to use Scriptaculous or any other code based on Prototype, I
would need to do the same thing.
Summary: having Prototype and jQuery rely on the same function (the
same name) both with different functionalities screwed us.
On the other hand, a workaround would be add some request filter or
dispatcher that detects jQuery plugins and replaces $() with jQuery().
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Switch from Prototype to jQuery?
Posted by Onno Scheffers <on...@piraya.nl>.
>
> I agree with you. Most T5 users have projects that rely on Prototype
> now, so plain switching to jQuery would break backward compatibility.
I agree as well. But I don't think there's a need to play the
backward-compatibility card here since removing the dependencies doesn't
need to break backward compatibility.
If Tapestry doesn't depend on any framework at all (just plain Javascript),
extensions based on Prototype will still work if the libraries are included
into the pages. It just means Tapestry can do without it.
It makes the barrier to entry for developers much lower if if the developer
can use whatever (s)he's used to. I know you can still use jQuery together
with Prototype (that's what I do), but since Prototype is already there, a
lot of developers will try and use that because they don't want to force any
more js-libraries onto their users than the ones already being included.
Learning another javascript framework or even having to rewrite existing
Javascript code to another web-framework is time-consuming and error-prone.
regards,
Onno
Re: Switch from Prototype to jQuery?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, Jun 10, 2009 at 8:02 AM, ice<fr...@gmail.com> wrote:
> Standing from the point of view that i prefer jQuery to prototype, i would
> like to see (Tapestry 5.2? ) a move into breaking down what the core web
> functionalities, from those that depend on Javascript, particularly any
> extensions, such as Prototype. But plain switching to jQuery is even worse.
I agree with you. Most T5 users have projects that rely on Prototype
now, so plain switching to jQuery would break backward compatibility.
And this is a very serious issue for Tapestry, being the source of
many complaints in the past.
> A web framework shouldn't be tied to specific javascript/effects library
> such as Prototype+Script.aculo.us
> By extracting out all the components that rely heavily on dynamic javascript
> behaviour into its own module, you divide and conquer. With a small layer of
> abstraction on the core functionalities when needed, and on top of it, allow
> people to use the javascript framework of their choice, and encourage more
> people to actually add support.
I agree 100%. The probleme here is the amount of work that needs to be
done. Even Howard, Tapestry creator and main committer, has though of
that, but there are other priorities. There is an issue,
https://issues.apache.org/jira/browse/TAP5-486, to discuss this.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org