You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by bmarvell <ma...@gmail.com> on 2007/09/05 11:47:18 UTC
JavaScript Frameworks
Hello all,
This is my first post so please be gentle ;)
I'm a user interface developer (no Java) working on what will inevitably be
a fairly heavy Ajax wicket project. After looking at a number of Ajax
examples and pre built widgets I have to say I'm a little puzzled! Why does
wickets core JS framework not use one of the main JS frameworks that are
available such as jQuery, Dojo or Prototype? I believe you have a hand
rolled version of mootools (although I may be wrong). Do the Wicket core
team plan on supporting and enriching this hand rolled framework alone?
Surely it would make more sense to choose one of the main JS frameworks that
have dedicated teams of devs supporting it?
Also I've found that Ajax widgets in wicket seem quite "here and there" in
their implementation. Some demos use prototype, some use YUI (a datepicker
for example). Doesnt this go against what JS frameworks are trying to
provide? Choosing a decent framework such as jQuery or Prototype will give
the developer a solid toolkit on which they can build, so extra components
such as datepickers or custom widgets can be applied as "Plugins". Sticking
to one framework reduces hits to the server, bandwidth, load and processing
times all of which imho are good things.
My worry at the moment is that the demos in wicket are very "lets get it
working on the frontend" and not "lets think about a framework and its rich
functionality".
SO to summarize :) are there any thoughts about using a single, supported
framework in wicket and moving forward from there?
Cheers,
Ben
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Gerolf Seitz <ge...@gmail.com>.
i'm not able to give you a deep insight answer on this, but rather what i
picked up on this topic:
@choosing one major JS framework:
i guess the core-devs didn't want to bet all their money on a single horse
(except maybe if it's their own ;) ).
then also some have a preference for a specific JS framework, others for
another one, so which one should be chosen? decisions aren't only grounded
on hard facts.
and not every license is compatible with ASL2.0 (damn license issues).
@dedicated devs supporting their JS framework:
while this (outsourcing) may sound good at first sight, when it comes to
getting a certain bug fixed or a wicket-specific feature added will probably
not be that much fun. and i'm not even talking about waiting for a stable
version to be released. what if a new version gets released that fixes a
major bug but breaks other stuff?
having control over something that lives in the core of wicket (meaning the
wicket project) is rather crucial, i think. of course this also means
putting a lot of effort into it (wicket-ajax.js has about 1900 loc). i guess
matej and igor could elaborate more on this.
please, anybody correct me if i got it wrong ;)
gerolf
On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>
>
> Hello all,
>
> This is my first post so please be gentle ;)
>
> I'm a user interface developer (no Java) working on what will inevitably
> be
> a fairly heavy Ajax wicket project. After looking at a number of Ajax
> examples and pre built widgets I have to say I'm a little puzzled! Why
> does
> wickets core JS framework not use one of the main JS frameworks that are
> available such as jQuery, Dojo or Prototype? I believe you have a hand
> rolled version of mootools (although I may be wrong). Do the Wicket core
> team plan on supporting and enriching this hand rolled framework alone?
> Surely it would make more sense to choose one of the main JS frameworks
> that
> have dedicated teams of devs supporting it?
>
> Also I've found that Ajax widgets in wicket seem quite "here and there" in
> their implementation. Some demos use prototype, some use YUI (a datepicker
>
> for example). Doesnt this go against what JS frameworks are trying to
> provide? Choosing a decent framework such as jQuery or Prototype will give
> the developer a solid toolkit on which they can build, so extra components
>
> such as datepickers or custom widgets can be applied as "Plugins".
> Sticking
> to one framework reduces hits to the server, bandwidth, load and
> processing
> times all of which imho are good things.
>
> My worry at the moment is that the demos in wicket are very "lets get it
> working on the frontend" and not "lets think about a framework and its
> rich
> functionality".
>
> SO to summarize :) are there any thoughts about using a single, supported
> framework in wicket and moving forward from there?
>
> Cheers,
>
> Ben
> --
> View this message in context:
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: JavaScript Frameworks
Posted by Igor Vaynberg <ig...@gmail.com>.
in reality wicket _does not_ ship with a javascript framework, all the
javascript that ships with wicket is meant for internal use only.
we did in fact start out with prototype, or ricoh, or one of those big
players as the back end, but we immediately ran into several issues:
these libs do not namespace themselves, so if we use prototype our users can
never use mootools or jquery because they are incompatible.
wicket ajax is very different, these libs are centered around making an ajax
request and sending back data, then applying that data to the dom through
client-written js. wicket requests send back markup that is then plugged in
- a totally different and completely transparent concept. and as matej
mentioned we have built, out of necessity, some pretty advanced features
that other libs do not provide.
we have namespaced all of our javascript so it does not interfere with
anything, which leaves you with unlimited choice of mixing and matching
other js libs in your code.
what this allows us to do is to mix and match components. yes, it would be
nice if we could all agree on a single js lib and build out a complete suite
of components based on it, but we have not yet. our users have started
building out these suites in projects like wicketstuff-yui,
wicketstuff-dojo, etc.
-igor
On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>
>
> Hello all,
>
> This is my first post so please be gentle ;)
>
> I'm a user interface developer (no Java) working on what will inevitably
> be
> a fairly heavy Ajax wicket project. After looking at a number of Ajax
> examples and pre built widgets I have to say I'm a little puzzled! Why
> does
> wickets core JS framework not use one of the main JS frameworks that are
> available such as jQuery, Dojo or Prototype? I believe you have a hand
> rolled version of mootools (although I may be wrong). Do the Wicket core
> team plan on supporting and enriching this hand rolled framework alone?
> Surely it would make more sense to choose one of the main JS frameworks
> that
> have dedicated teams of devs supporting it?
>
> Also I've found that Ajax widgets in wicket seem quite "here and there" in
> their implementation. Some demos use prototype, some use YUI (a datepicker
> for example). Doesnt this go against what JS frameworks are trying to
> provide? Choosing a decent framework such as jQuery or Prototype will give
> the developer a solid toolkit on which they can build, so extra components
> such as datepickers or custom widgets can be applied as "Plugins".
> Sticking
> to one framework reduces hits to the server, bandwidth, load and
> processing
> times all of which imho are good things.
>
> My worry at the moment is that the demos in wicket are very "lets get it
> working on the frontend" and not "lets think about a framework and its
> rich
> functionality".
>
> SO to summarize :) are there any thoughts about using a single, supported
> framework in wicket and moving forward from there?
>
> Cheers,
>
> Ben
> --
> View this message in context:
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: JavaScript Frameworks
Posted by Sam Hough <sa...@redspr.com>.
Johan,
We have been "shopping" for components recently and also worried about
JavaScript/DOM bloat. The wicket-datetime jar uses YUI (Yahoo I think) and
we decided not to use it as we were not sure we wanted to commit to YUI.
We have customers in Africa using our servers in the UK. Since their
bandwidth may be very poor reducing the amount they have to download is
important. It may be fine once cached but it is hard to get past that
initial impression that because the browser is downloading two or three
libraries on first use it seems slow. Sales team are keen on this for demos!
Almost a bigger worry for me was trying to debug obscure issues when more
than one library has started messing with the DOM...
I'm a bit fussy about jar bloat (used Alfresco recently!) but JS library
bloat is obviously more of a performance issue. At least we don't have to
worry about logging APIs ;)
Johan Compagner wrote:
>
> Purely visual javascript libs don't have anything to do with wicket.
> Thats just dhtml/javascript programming.
> Especially as you said that you also want to bind those events on the
> clientside
> What should wicket do then with those libs? (besides maybe serving them)
>
> johan
>
>
> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>
>>
>> This is true but as you're actively checking JavaScript framework bits in
>> I
>> thought I'd ask if you have any plans to pick one framework and stick
>> with
>> it.
>>
>> I've already spotted some YUI bits and now animation.js is going in it
>> just
>> feels a little scattered...
>>
>> Especially when the animations and other common widgets are all available
>> through one framework be it YUI, jQuery or Prototype...
>>
>> I can see the need for wickets custom Ajax stuff so maybe there should be
>> a
>> real push to use another framework for all the widget/visual
>> representation.
>>
>> Then my users wont need to download wicket-ajax + YUI + animation.js when
>> I
>> wanna have a fading calendar that does ajax calls ;)
>>
>> Ben.
>>
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > Well, you can use whatever Ajax/javascript framework you want.
>> > Wicket-ajax should work with all major js frameworks. It's not really
>> > meant to be used outside wicket, as we don't guarantee api stability
>> > of wicket-ajax (but that doesn't mean you can't use it though).
>> >
>> > We try to keep the footprint as low as possible, so that it gives you
>> > minimum overhead if you want to use a custom framework too.
>> >
>> > -Matej
>> >
>> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >>
>> >> Agreed hence why I said I was coining the _business_ term.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > stupid thing is that all those slides and fades and fancy ui things
>> are
>> >> > not
>> >> > really ajax..
>> >> > thats just JavaScript/DHTML
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> Sorry if this has been asked several times but it I didn't easily
>> find
>> >> it
>> >> >> from a search.
>> >> >>
>> >> >> Fair enough about the actual "Ajax" functionality if specific code
>> is
>> >> >> required fair enough.
>> >> >>
>> >> >> I was using the term Ajax in a very business sense ie: full stack
>> >> >> functionality; slides, fades etc.
>> >> >>
>> >> >> So for those specific issues are we to say:
>> >> >>
>> >> >>
>> >> >>
>> >>
>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>> >> >>
>> >> >> Is the future??
>> >> >>
>> >> >>
>> >> >> Matej Knopp-2 wrote:
>> >> >> >
>> >> >> > Hi,
>> >> >> >
>> >> >> > this question has been asked here numerous times. The thing is,
>> >> there
>> >> >> > is in fact no real alternative of wicket-ajax for us.
>> >> >> >
>> >> >> > Wicket is not built about Ajax widgets.Wicket is about
>> server-side
>> >> >> > components that can be partially updated using Ajax. That's a
>> >> >> > fundamental difference.
>> >> >> >
>> >> >> > As for the features, wicket-ajax has numerous advanced features
>> such
>> >> as
>> >> >> > - asynchronous pipeline that allows loading dependencies in
>> >> >> > asynchronous way, yet respecting the order (unlike e.g. dojo
>> where
>> >> the
>> >> >> > depending javascript are loaded using synchronous http requests
>> >> which
>> >> >> > block entire browser = usability disaster)
>> >> >> > - ajax channels that allow you to stack or drop pending requests
>> >> >> > - multipart ajax response for replacing multiple components in
>> one
>> >> >> > response, ajax header contribution processing (so that component
>> can
>> >> >> > render header response as it would normally do, wicket
>> transparently
>> >> >> > processes it and loads all dependencies (javascript references,
>> >> >> > stylesheets, etc) in an asynchronous way while respecting the
>> order)
>> >> >> > - wicket-ajax.js is about 7kb compressed (with stripped down
>> >> >> > comments). As this is a general purpose ajax framework, the size
>> >> >> > matters. For sites where you using ajax only on certain places,
>> >> having
>> >> >> > a 200kb javascript dependency would be quite a burden
>> >> >> > - there's more to it, the code is quite well documented, if you
>> are
>> >> >> > interested you can dig into it, also you should search achives,
>> this
>> >> >> > has been discussed here already.
>> >> >> >
>> >> >> > -Matej
>> >> >> >
>> >> >> >
>> >> >> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >> >> >>
>> >> >> >> Hello all,
>> >> >> >>
>> >> >> >> This is my first post so please be gentle ;)
>> >> >> >>
>> >> >> >> I'm a user interface developer (no Java) working on what will
>> >> >> inevitably
>> >> >> >> be
>> >> >> >> a fairly heavy Ajax wicket project. After looking at a number of
>> >> Ajax
>> >> >> >> examples and pre built widgets I have to say I'm a little
>> puzzled!
>> >> Why
>> >> >> >> does
>> >> >> >> wickets core JS framework not use one of the main JS frameworks
>> >> that
>> >> >> are
>> >> >> >> available such as jQuery, Dojo or Prototype? I believe you have
>> a
>> >> hand
>> >> >> >> rolled version of mootools (although I may be wrong). Do the
>> Wicket
>> >> >> core
>> >> >> >> team plan on supporting and enriching this hand rolled framework
>> >> >> alone?
>> >> >> >> Surely it would make more sense to choose one of the main JS
>> >> >> frameworks
>> >> >> >> that
>> >> >> >> have dedicated teams of devs supporting it?
>> >> >> >>
>> >> >> >> Also I've found that Ajax widgets in wicket seem quite "here and
>> >> >> there"
>> >> >> >> in
>> >> >> >> their implementation. Some demos use prototype, some use YUI (a
>> >> >> >> datepicker
>> >> >> >> for example). Doesnt this go against what JS frameworks are
>> trying
>> >> to
>> >> >> >> provide? Choosing a decent framework such as jQuery or Prototype
>> >> will
>> >> >> >> give
>> >> >> >> the developer a solid toolkit on which they can build, so extra
>> >> >> >> components
>> >> >> >> such as datepickers or custom widgets can be applied as
>> "Plugins".
>> >> >> >> Sticking
>> >> >> >> to one framework reduces hits to the server, bandwidth, load and
>> >> >> >> processing
>> >> >> >> times all of which imho are good things.
>> >> >> >>
>> >> >> >> My worry at the moment is that the demos in wicket are very
>> "lets
>> >> get
>> >> >> it
>> >> >> >> working on the frontend" and not "lets think about a framework
>> and
>> >> its
>> >> >> >> rich
>> >> >> >> functionality".
>> >> >> >>
>> >> >> >> SO to summarize :) are there any thoughts about using a single,
>> >> >> supported
>> >> >> >> framework in wicket and moving forward from there?
>> >> >> >>
>> >> >> >> Cheers,
>> >> >> >>
>> >> >> >> Ben
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496187
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496872
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12497476
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Johan Compagner <jc...@gmail.com>.
Purely visual javascript libs don't have anything to do with wicket.
Thats just dhtml/javascript programming.
Especially as you said that you also want to bind those events on the
clientside
What should wicket do then with those libs? (besides maybe serving them)
johan
On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>
>
> This is true but as you're actively checking JavaScript framework bits in
> I
> thought I'd ask if you have any plans to pick one framework and stick with
> it.
>
> I've already spotted some YUI bits and now animation.js is going in it
> just
> feels a little scattered...
>
> Especially when the animations and other common widgets are all available
> through one framework be it YUI, jQuery or Prototype...
>
> I can see the need for wickets custom Ajax stuff so maybe there should be
> a
> real push to use another framework for all the widget/visual
> representation.
>
> Then my users wont need to download wicket-ajax + YUI + animation.js when
> I
> wanna have a fading calendar that does ajax calls ;)
>
> Ben.
>
>
>
> Matej Knopp-2 wrote:
> >
> > Well, you can use whatever Ajax/javascript framework you want.
> > Wicket-ajax should work with all major js frameworks. It's not really
> > meant to be used outside wicket, as we don't guarantee api stability
> > of wicket-ajax (but that doesn't mean you can't use it though).
> >
> > We try to keep the footprint as low as possible, so that it gives you
> > minimum overhead if you want to use a custom framework too.
> >
> > -Matej
> >
> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >>
> >> Agreed hence why I said I was coining the _business_ term.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > stupid thing is that all those slides and fades and fancy ui things
> are
> >> > not
> >> > really ajax..
> >> > thats just JavaScript/DHTML
> >> >
> >> > johan
> >> >
> >> >
> >> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> Sorry if this has been asked several times but it I didn't easily
> find
> >> it
> >> >> from a search.
> >> >>
> >> >> Fair enough about the actual "Ajax" functionality if specific code
> is
> >> >> required fair enough.
> >> >>
> >> >> I was using the term Ajax in a very business sense ie: full stack
> >> >> functionality; slides, fades etc.
> >> >>
> >> >> So for those specific issues are we to say:
> >> >>
> >> >>
> >> >>
> >>
> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
> >> >>
> >> >> Is the future??
> >> >>
> >> >>
> >> >> Matej Knopp-2 wrote:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > this question has been asked here numerous times. The thing is,
> >> there
> >> >> > is in fact no real alternative of wicket-ajax for us.
> >> >> >
> >> >> > Wicket is not built about Ajax widgets.Wicket is about server-side
> >> >> > components that can be partially updated using Ajax. That's a
> >> >> > fundamental difference.
> >> >> >
> >> >> > As for the features, wicket-ajax has numerous advanced features
> such
> >> as
> >> >> > - asynchronous pipeline that allows loading dependencies in
> >> >> > asynchronous way, yet respecting the order (unlike e.g. dojo where
> >> the
> >> >> > depending javascript are loaded using synchronous http requests
> >> which
> >> >> > block entire browser = usability disaster)
> >> >> > - ajax channels that allow you to stack or drop pending requests
> >> >> > - multipart ajax response for replacing multiple components in one
> >> >> > response, ajax header contribution processing (so that component
> can
> >> >> > render header response as it would normally do, wicket
> transparently
> >> >> > processes it and loads all dependencies (javascript references,
> >> >> > stylesheets, etc) in an asynchronous way while respecting the
> order)
> >> >> > - wicket-ajax.js is about 7kb compressed (with stripped down
> >> >> > comments). As this is a general purpose ajax framework, the size
> >> >> > matters. For sites where you using ajax only on certain places,
> >> having
> >> >> > a 200kb javascript dependency would be quite a burden
> >> >> > - there's more to it, the code is quite well documented, if you
> are
> >> >> > interested you can dig into it, also you should search achives,
> this
> >> >> > has been discussed here already.
> >> >> >
> >> >> > -Matej
> >> >> >
> >> >> >
> >> >> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >> >> >>
> >> >> >> Hello all,
> >> >> >>
> >> >> >> This is my first post so please be gentle ;)
> >> >> >>
> >> >> >> I'm a user interface developer (no Java) working on what will
> >> >> inevitably
> >> >> >> be
> >> >> >> a fairly heavy Ajax wicket project. After looking at a number of
> >> Ajax
> >> >> >> examples and pre built widgets I have to say I'm a little
> puzzled!
> >> Why
> >> >> >> does
> >> >> >> wickets core JS framework not use one of the main JS frameworks
> >> that
> >> >> are
> >> >> >> available such as jQuery, Dojo or Prototype? I believe you have a
> >> hand
> >> >> >> rolled version of mootools (although I may be wrong). Do the
> Wicket
> >> >> core
> >> >> >> team plan on supporting and enriching this hand rolled framework
> >> >> alone?
> >> >> >> Surely it would make more sense to choose one of the main JS
> >> >> frameworks
> >> >> >> that
> >> >> >> have dedicated teams of devs supporting it?
> >> >> >>
> >> >> >> Also I've found that Ajax widgets in wicket seem quite "here and
> >> >> there"
> >> >> >> in
> >> >> >> their implementation. Some demos use prototype, some use YUI (a
> >> >> >> datepicker
> >> >> >> for example). Doesnt this go against what JS frameworks are
> trying
> >> to
> >> >> >> provide? Choosing a decent framework such as jQuery or Prototype
> >> will
> >> >> >> give
> >> >> >> the developer a solid toolkit on which they can build, so extra
> >> >> >> components
> >> >> >> such as datepickers or custom widgets can be applied as
> "Plugins".
> >> >> >> Sticking
> >> >> >> to one framework reduces hits to the server, bandwidth, load and
> >> >> >> processing
> >> >> >> times all of which imho are good things.
> >> >> >>
> >> >> >> My worry at the moment is that the demos in wicket are very "lets
> >> get
> >> >> it
> >> >> >> working on the frontend" and not "lets think about a framework
> and
> >> its
> >> >> >> rich
> >> >> >> functionality".
> >> >> >>
> >> >> >> SO to summarize :) are there any thoughts about using a single,
> >> >> supported
> >> >> >> framework in wicket and moving forward from there?
> >> >> >>
> >> >> >> Cheers,
> >> >> >>
> >> >> >> Ben
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496187
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496872
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: JavaScript Frameworks
Posted by bmarvell <ma...@gmail.com>.
This is true but as you're actively checking JavaScript framework bits in I
thought I'd ask if you have any plans to pick one framework and stick with
it.
I've already spotted some YUI bits and now animation.js is going in it just
feels a little scattered...
Especially when the animations and other common widgets are all available
through one framework be it YUI, jQuery or Prototype...
I can see the need for wickets custom Ajax stuff so maybe there should be a
real push to use another framework for all the widget/visual representation.
Then my users wont need to download wicket-ajax + YUI + animation.js when I
wanna have a fading calendar that does ajax calls ;)
Ben.
Matej Knopp-2 wrote:
>
> Well, you can use whatever Ajax/javascript framework you want.
> Wicket-ajax should work with all major js frameworks. It's not really
> meant to be used outside wicket, as we don't guarantee api stability
> of wicket-ajax (but that doesn't mean you can't use it though).
>
> We try to keep the footprint as low as possible, so that it gives you
> minimum overhead if you want to use a custom framework too.
>
> -Matej
>
> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>
>> Agreed hence why I said I was coining the _business_ term.
>>
>>
>> Johan Compagner wrote:
>> >
>> > stupid thing is that all those slides and fades and fancy ui things are
>> > not
>> > really ajax..
>> > thats just JavaScript/DHTML
>> >
>> > johan
>> >
>> >
>> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >>
>> >>
>> >> Sorry if this has been asked several times but it I didn't easily find
>> it
>> >> from a search.
>> >>
>> >> Fair enough about the actual "Ajax" functionality if specific code is
>> >> required fair enough.
>> >>
>> >> I was using the term Ajax in a very business sense ie: full stack
>> >> functionality; slides, fades etc.
>> >>
>> >> So for those specific issues are we to say:
>> >>
>> >>
>> >>
>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>> >>
>> >> Is the future??
>> >>
>> >>
>> >> Matej Knopp-2 wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > this question has been asked here numerous times. The thing is,
>> there
>> >> > is in fact no real alternative of wicket-ajax for us.
>> >> >
>> >> > Wicket is not built about Ajax widgets.Wicket is about server-side
>> >> > components that can be partially updated using Ajax. That's a
>> >> > fundamental difference.
>> >> >
>> >> > As for the features, wicket-ajax has numerous advanced features such
>> as
>> >> > - asynchronous pipeline that allows loading dependencies in
>> >> > asynchronous way, yet respecting the order (unlike e.g. dojo where
>> the
>> >> > depending javascript are loaded using synchronous http requests
>> which
>> >> > block entire browser = usability disaster)
>> >> > - ajax channels that allow you to stack or drop pending requests
>> >> > - multipart ajax response for replacing multiple components in one
>> >> > response, ajax header contribution processing (so that component can
>> >> > render header response as it would normally do, wicket transparently
>> >> > processes it and loads all dependencies (javascript references,
>> >> > stylesheets, etc) in an asynchronous way while respecting the order)
>> >> > - wicket-ajax.js is about 7kb compressed (with stripped down
>> >> > comments). As this is a general purpose ajax framework, the size
>> >> > matters. For sites where you using ajax only on certain places,
>> having
>> >> > a 200kb javascript dependency would be quite a burden
>> >> > - there's more to it, the code is quite well documented, if you are
>> >> > interested you can dig into it, also you should search achives, this
>> >> > has been discussed here already.
>> >> >
>> >> > -Matej
>> >> >
>> >> >
>> >> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >> >>
>> >> >> Hello all,
>> >> >>
>> >> >> This is my first post so please be gentle ;)
>> >> >>
>> >> >> I'm a user interface developer (no Java) working on what will
>> >> inevitably
>> >> >> be
>> >> >> a fairly heavy Ajax wicket project. After looking at a number of
>> Ajax
>> >> >> examples and pre built widgets I have to say I'm a little puzzled!
>> Why
>> >> >> does
>> >> >> wickets core JS framework not use one of the main JS frameworks
>> that
>> >> are
>> >> >> available such as jQuery, Dojo or Prototype? I believe you have a
>> hand
>> >> >> rolled version of mootools (although I may be wrong). Do the Wicket
>> >> core
>> >> >> team plan on supporting and enriching this hand rolled framework
>> >> alone?
>> >> >> Surely it would make more sense to choose one of the main JS
>> >> frameworks
>> >> >> that
>> >> >> have dedicated teams of devs supporting it?
>> >> >>
>> >> >> Also I've found that Ajax widgets in wicket seem quite "here and
>> >> there"
>> >> >> in
>> >> >> their implementation. Some demos use prototype, some use YUI (a
>> >> >> datepicker
>> >> >> for example). Doesnt this go against what JS frameworks are trying
>> to
>> >> >> provide? Choosing a decent framework such as jQuery or Prototype
>> will
>> >> >> give
>> >> >> the developer a solid toolkit on which they can build, so extra
>> >> >> components
>> >> >> such as datepickers or custom widgets can be applied as "Plugins".
>> >> >> Sticking
>> >> >> to one framework reduces hits to the server, bandwidth, load and
>> >> >> processing
>> >> >> times all of which imho are good things.
>> >> >>
>> >> >> My worry at the moment is that the demos in wicket are very "lets
>> get
>> >> it
>> >> >> working on the frontend" and not "lets think about a framework and
>> its
>> >> >> rich
>> >> >> functionality".
>> >> >>
>> >> >> SO to summarize :) are there any thoughts about using a single,
>> >> supported
>> >> >> framework in wicket and moving forward from there?
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Ben
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496187
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496872
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Matej Knopp <ma...@gmail.com>.
Well, you can use whatever Ajax/javascript framework you want.
Wicket-ajax should work with all major js frameworks. It's not really
meant to be used outside wicket, as we don't guarantee api stability
of wicket-ajax (but that doesn't mean you can't use it though).
We try to keep the footprint as low as possible, so that it gives you
minimum overhead if you want to use a custom framework too.
-Matej
On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>
> Agreed hence why I said I was coining the _business_ term.
>
>
> Johan Compagner wrote:
> >
> > stupid thing is that all those slides and fades and fancy ui things are
> > not
> > really ajax..
> > thats just JavaScript/DHTML
> >
> > johan
> >
> >
> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >>
> >>
> >> Sorry if this has been asked several times but it I didn't easily find it
> >> from a search.
> >>
> >> Fair enough about the actual "Ajax" functionality if specific code is
> >> required fair enough.
> >>
> >> I was using the term Ajax in a very business sense ie: full stack
> >> functionality; slides, fades etc.
> >>
> >> So for those specific issues are we to say:
> >>
> >>
> >> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
> >>
> >> Is the future??
> >>
> >>
> >> Matej Knopp-2 wrote:
> >> >
> >> > Hi,
> >> >
> >> > this question has been asked here numerous times. The thing is, there
> >> > is in fact no real alternative of wicket-ajax for us.
> >> >
> >> > Wicket is not built about Ajax widgets.Wicket is about server-side
> >> > components that can be partially updated using Ajax. That's a
> >> > fundamental difference.
> >> >
> >> > As for the features, wicket-ajax has numerous advanced features such as
> >> > - asynchronous pipeline that allows loading dependencies in
> >> > asynchronous way, yet respecting the order (unlike e.g. dojo where the
> >> > depending javascript are loaded using synchronous http requests which
> >> > block entire browser = usability disaster)
> >> > - ajax channels that allow you to stack or drop pending requests
> >> > - multipart ajax response for replacing multiple components in one
> >> > response, ajax header contribution processing (so that component can
> >> > render header response as it would normally do, wicket transparently
> >> > processes it and loads all dependencies (javascript references,
> >> > stylesheets, etc) in an asynchronous way while respecting the order)
> >> > - wicket-ajax.js is about 7kb compressed (with stripped down
> >> > comments). As this is a general purpose ajax framework, the size
> >> > matters. For sites where you using ajax only on certain places, having
> >> > a 200kb javascript dependency would be quite a burden
> >> > - there's more to it, the code is quite well documented, if you are
> >> > interested you can dig into it, also you should search achives, this
> >> > has been discussed here already.
> >> >
> >> > -Matej
> >> >
> >> >
> >> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >> >>
> >> >> Hello all,
> >> >>
> >> >> This is my first post so please be gentle ;)
> >> >>
> >> >> I'm a user interface developer (no Java) working on what will
> >> inevitably
> >> >> be
> >> >> a fairly heavy Ajax wicket project. After looking at a number of Ajax
> >> >> examples and pre built widgets I have to say I'm a little puzzled! Why
> >> >> does
> >> >> wickets core JS framework not use one of the main JS frameworks that
> >> are
> >> >> available such as jQuery, Dojo or Prototype? I believe you have a hand
> >> >> rolled version of mootools (although I may be wrong). Do the Wicket
> >> core
> >> >> team plan on supporting and enriching this hand rolled framework
> >> alone?
> >> >> Surely it would make more sense to choose one of the main JS
> >> frameworks
> >> >> that
> >> >> have dedicated teams of devs supporting it?
> >> >>
> >> >> Also I've found that Ajax widgets in wicket seem quite "here and
> >> there"
> >> >> in
> >> >> their implementation. Some demos use prototype, some use YUI (a
> >> >> datepicker
> >> >> for example). Doesnt this go against what JS frameworks are trying to
> >> >> provide? Choosing a decent framework such as jQuery or Prototype will
> >> >> give
> >> >> the developer a solid toolkit on which they can build, so extra
> >> >> components
> >> >> such as datepickers or custom widgets can be applied as "Plugins".
> >> >> Sticking
> >> >> to one framework reduces hits to the server, bandwidth, load and
> >> >> processing
> >> >> times all of which imho are good things.
> >> >>
> >> >> My worry at the moment is that the demos in wicket are very "lets get
> >> it
> >> >> working on the frontend" and not "lets think about a framework and its
> >> >> rich
> >> >> functionality".
> >> >>
> >> >> SO to summarize :) are there any thoughts about using a single,
> >> supported
> >> >> framework in wicket and moving forward from there?
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Ben
> >> >> --
> >> >> View this message in context:
> >> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496187
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by bmarvell <ma...@gmail.com>.
Agreed hence why I said I was coining the _business_ term.
Johan Compagner wrote:
>
> stupid thing is that all those slides and fades and fancy ui things are
> not
> really ajax..
> thats just JavaScript/DHTML
>
> johan
>
>
> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>
>>
>> Sorry if this has been asked several times but it I didn't easily find it
>> from a search.
>>
>> Fair enough about the actual "Ajax" functionality if specific code is
>> required fair enough.
>>
>> I was using the term Ajax in a very business sense ie: full stack
>> functionality; slides, fades etc.
>>
>> So for those specific issues are we to say:
>>
>>
>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>>
>> Is the future??
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > Hi,
>> >
>> > this question has been asked here numerous times. The thing is, there
>> > is in fact no real alternative of wicket-ajax for us.
>> >
>> > Wicket is not built about Ajax widgets.Wicket is about server-side
>> > components that can be partially updated using Ajax. That's a
>> > fundamental difference.
>> >
>> > As for the features, wicket-ajax has numerous advanced features such as
>> > - asynchronous pipeline that allows loading dependencies in
>> > asynchronous way, yet respecting the order (unlike e.g. dojo where the
>> > depending javascript are loaded using synchronous http requests which
>> > block entire browser = usability disaster)
>> > - ajax channels that allow you to stack or drop pending requests
>> > - multipart ajax response for replacing multiple components in one
>> > response, ajax header contribution processing (so that component can
>> > render header response as it would normally do, wicket transparently
>> > processes it and loads all dependencies (javascript references,
>> > stylesheets, etc) in an asynchronous way while respecting the order)
>> > - wicket-ajax.js is about 7kb compressed (with stripped down
>> > comments). As this is a general purpose ajax framework, the size
>> > matters. For sites where you using ajax only on certain places, having
>> > a 200kb javascript dependency would be quite a burden
>> > - there's more to it, the code is quite well documented, if you are
>> > interested you can dig into it, also you should search achives, this
>> > has been discussed here already.
>> >
>> > -Matej
>> >
>> >
>> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >>
>> >> Hello all,
>> >>
>> >> This is my first post so please be gentle ;)
>> >>
>> >> I'm a user interface developer (no Java) working on what will
>> inevitably
>> >> be
>> >> a fairly heavy Ajax wicket project. After looking at a number of Ajax
>> >> examples and pre built widgets I have to say I'm a little puzzled! Why
>> >> does
>> >> wickets core JS framework not use one of the main JS frameworks that
>> are
>> >> available such as jQuery, Dojo or Prototype? I believe you have a hand
>> >> rolled version of mootools (although I may be wrong). Do the Wicket
>> core
>> >> team plan on supporting and enriching this hand rolled framework
>> alone?
>> >> Surely it would make more sense to choose one of the main JS
>> frameworks
>> >> that
>> >> have dedicated teams of devs supporting it?
>> >>
>> >> Also I've found that Ajax widgets in wicket seem quite "here and
>> there"
>> >> in
>> >> their implementation. Some demos use prototype, some use YUI (a
>> >> datepicker
>> >> for example). Doesnt this go against what JS frameworks are trying to
>> >> provide? Choosing a decent framework such as jQuery or Prototype will
>> >> give
>> >> the developer a solid toolkit on which they can build, so extra
>> >> components
>> >> such as datepickers or custom widgets can be applied as "Plugins".
>> >> Sticking
>> >> to one framework reduces hits to the server, bandwidth, load and
>> >> processing
>> >> times all of which imho are good things.
>> >>
>> >> My worry at the moment is that the demos in wicket are very "lets get
>> it
>> >> working on the frontend" and not "lets think about a framework and its
>> >> rich
>> >> functionality".
>> >>
>> >> SO to summarize :) are there any thoughts about using a single,
>> supported
>> >> framework in wicket and moving forward from there?
>> >>
>> >> Cheers,
>> >>
>> >> Ben
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496187
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Johan Compagner <jc...@gmail.com>.
stupid thing is that all those slides and fades and fancy ui things are not
really ajax..
thats just JavaScript/DHTML
johan
On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>
>
> Sorry if this has been asked several times but it I didn't easily find it
> from a search.
>
> Fair enough about the actual "Ajax" functionality if specific code is
> required fair enough.
>
> I was using the term Ajax in a very business sense ie: full stack
> functionality; slides, fades etc.
>
> So for those specific issues are we to say:
>
>
> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>
> Is the future??
>
>
> Matej Knopp-2 wrote:
> >
> > Hi,
> >
> > this question has been asked here numerous times. The thing is, there
> > is in fact no real alternative of wicket-ajax for us.
> >
> > Wicket is not built about Ajax widgets.Wicket is about server-side
> > components that can be partially updated using Ajax. That's a
> > fundamental difference.
> >
> > As for the features, wicket-ajax has numerous advanced features such as
> > - asynchronous pipeline that allows loading dependencies in
> > asynchronous way, yet respecting the order (unlike e.g. dojo where the
> > depending javascript are loaded using synchronous http requests which
> > block entire browser = usability disaster)
> > - ajax channels that allow you to stack or drop pending requests
> > - multipart ajax response for replacing multiple components in one
> > response, ajax header contribution processing (so that component can
> > render header response as it would normally do, wicket transparently
> > processes it and loads all dependencies (javascript references,
> > stylesheets, etc) in an asynchronous way while respecting the order)
> > - wicket-ajax.js is about 7kb compressed (with stripped down
> > comments). As this is a general purpose ajax framework, the size
> > matters. For sites where you using ajax only on certain places, having
> > a 200kb javascript dependency would be quite a burden
> > - there's more to it, the code is quite well documented, if you are
> > interested you can dig into it, also you should search achives, this
> > has been discussed here already.
> >
> > -Matej
> >
> >
> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >>
> >> Hello all,
> >>
> >> This is my first post so please be gentle ;)
> >>
> >> I'm a user interface developer (no Java) working on what will
> inevitably
> >> be
> >> a fairly heavy Ajax wicket project. After looking at a number of Ajax
> >> examples and pre built widgets I have to say I'm a little puzzled! Why
> >> does
> >> wickets core JS framework not use one of the main JS frameworks that
> are
> >> available such as jQuery, Dojo or Prototype? I believe you have a hand
> >> rolled version of mootools (although I may be wrong). Do the Wicket
> core
> >> team plan on supporting and enriching this hand rolled framework alone?
> >> Surely it would make more sense to choose one of the main JS frameworks
> >> that
> >> have dedicated teams of devs supporting it?
> >>
> >> Also I've found that Ajax widgets in wicket seem quite "here and there"
> >> in
> >> their implementation. Some demos use prototype, some use YUI (a
> >> datepicker
> >> for example). Doesnt this go against what JS frameworks are trying to
> >> provide? Choosing a decent framework such as jQuery or Prototype will
> >> give
> >> the developer a solid toolkit on which they can build, so extra
> >> components
> >> such as datepickers or custom widgets can be applied as "Plugins".
> >> Sticking
> >> to one framework reduces hits to the server, bandwidth, load and
> >> processing
> >> times all of which imho are good things.
> >>
> >> My worry at the moment is that the demos in wicket are very "lets get
> it
> >> working on the frontend" and not "lets think about a framework and its
> >> rich
> >> functionality".
> >>
> >> SO to summarize :) are there any thoughts about using a single,
> supported
> >> framework in wicket and moving forward from there?
> >>
> >> Cheers,
> >>
> >> Ben
> >> --
> >> View this message in context:
> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: JavaScript Frameworks
Posted by bmarvell <ma...@gmail.com>.
Sure i wanna do "real programming" in javascript.
My issue was, the back end devs here can tap away writing wicket but it wont
cover 100% of the interactions that are needed on the front end. So I hoped
that if wicked used a preferred JS framework for some of its widgets I could
save alot of overhead and go with that on the _other_ frontend interactions
i have to deal with.
Anyways, thanks for the help people.
Johan Compagner wrote:
>
> ahh so you want to do real programming in the javascript?
> So attaching purely in client side javascript events and those events call
> the server?
>
> Thats not how wicket works, in wicket you normally don't program
> javascript
> you get it pushed
> and the events get attached by the serverside.
>
> johan
>
>
> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>
>>
>> Sorry,
>>
>> Again mine is coming from a very front end perspective ie writing JS in a
>> progressive enhancement style.
>>
>> Your pseudo code looks like the other end of the spectrum ie java code
>>
>> My main point over this thread was to also appreciate that while wicket
>> is
>> designed for java devs it needs to have JS framework code that can be
>> used
>> by UI developers.
>>
>> Hence why I believe having the ability to write things in a front end way
>> is
>> a GOOD thing.
>>
>>
>>
>> Nino Saturnino Martinez Vazquez Wael wrote:
>> >
>> > hmm I'll have to take a deeper look into this.
>> >
>> > The main idea about the input events are that you should be able to
>> just
>> > add events of any sort (mouse, key, time?) to anycomponent that will
>> > either trigger that component or another, this means triggering from
>> > client to server. No real work has been done on the input events
>> project
>> > other that the project are setup on the stuff svn, also some base
>> > infrastructure has been done.
>> >
>> > pseudo code example:
>> >
>> > form myform;
>> >
>> > label.add(new Event(Events.keypressed(a),Event.keydown, myform));
>> >
>> > above should trigger myform when a are pressed and label has focus.
>> >
>> > disclaimer : this might be bad example:)
>> >
>> > regards Nino
>> >
>> > bmarvell wrote:
>> >> I personally think a CSS DOM traversal/manipulation model that can tie
>> to
>> >> events elegantly is what's needed.
>> >>
>> >> i.e:
>> >>
>> >> http://jquery.com
>> >>
>> >> http://bennolan.com/behaviour/
>> >>
>> >> Being able to say:
>> >>
>> >> $("#somthing li").click(.....
>> >>
>> >> Is so much easier to code and read than:
>> >>
>> >> document.getElementById
>> ("something").getElementsByTagName("li")..........
>> >>
>> >>
>> >> Nino Saturnino Martinez Vazquez Wael wrote:
>> >>
>> >>> on the Events part I might aswell go on with the input events
>> contrib...
>> >>> As this now has been up a lot of times one the mailing list..
>> >>>
>> >>> I might seem to find some time to do it..
>> >>>
>> >>> But it would be really nice to see what people would like of features
>> >>> from it?
>> >>>
>> >>> regards Nino
>> >>>
>> >>> bmarvell wrote:
>> >>>
>> >>>> Right then so for completeness:
>> >>>>
>> >>>> * Ajax Calls [In house]
>> >>>> * Animation [animator.js]
>> >>>> * Dom manipulation and traversal (CSS style for this is becoming
>> highly
>> >>>> favourable) [??]
>> >>>> * Events [??]
>> >>>>
>> >>>> Has any of this been addressed or considered yet?
>> >>>>
>> >>>> I'm just coming in from the point of a front end developer and
>> trying
>> >>>> to
>> >>>> identify whats either missing or I cant find :confused:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> Gerolf Seitz wrote:
>> >>>>
>> >>>>
>> >>>>>> So for those specific issues are we to say:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>> >>>>>>
>> >>>>>> Is the future??
>> >>>>>>
>> >>>>>>
>> >>>>> in this case, take a look at
>> >>>>>
>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
>> >>>>> ;)
>> >>>>>
>> >>>>> gerolf
>> >>>>>
>> >>>>> Matej Knopp-2 wrote:
>> >>>>>
>> >>>>>
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>> this question has been asked here numerous times. The thing is,
>> >>>>>>> there
>> >>>>>>> is in fact no real alternative of wicket-ajax for us.
>> >>>>>>>
>> >>>>>>> Wicket is not built about Ajax widgets.Wicket is about
>> server-side
>> >>>>>>> components that can be partially updated using Ajax. That's a
>> >>>>>>> fundamental difference.
>> >>>>>>>
>> >>>>>>> As for the features, wicket-ajax has numerous advanced features
>> such
>> >>>>>>> as
>> >>>>>>> - asynchronous pipeline that allows loading dependencies in
>> >>>>>>> asynchronous way, yet respecting the order (unlike e.g. dojo
>> where
>> >>>>>>> the
>> >>>>>>> depending javascript are loaded using synchronous http requests
>> >>>>>>> which
>> >>>>>>> block entire browser = usability disaster)
>> >>>>>>> - ajax channels that allow you to stack or drop pending requests
>> >>>>>>> - multipart ajax response for replacing multiple components in
>> one
>> >>>>>>> response, ajax header contribution processing (so that component
>> can
>> >>>>>>> render header response as it would normally do, wicket
>> transparently
>> >>>>>>> processes it and loads all dependencies (javascript references,
>> >>>>>>> stylesheets, etc) in an asynchronous way while respecting the
>> order)
>> >>>>>>> - wicket-ajax.js is about 7kb compressed (with stripped down
>> >>>>>>> comments). As this is a general purpose ajax framework, the size
>> >>>>>>> matters. For sites where you using ajax only on certain places,
>> >>>>>>> having
>> >>>>>>> a 200kb javascript dependency would be quite a burden
>> >>>>>>> - there's more to it, the code is quite well documented, if you
>> are
>> >>>>>>> interested you can dig into it, also you should search achives,
>> this
>> >>>>>>> has been discussed here already.
>> >>>>>>>
>> >>>>>>> -Matej
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> Hello all,
>> >>>>>>>>
>> >>>>>>>> This is my first post so please be gentle ;)
>> >>>>>>>>
>> >>>>>>>> I'm a user interface developer (no Java) working on what will
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> inevitably
>> >>>>>>
>> >>>>>>
>> >>>>>>>> be
>> >>>>>>>> a fairly heavy Ajax wicket project. After looking at a number of
>> >>>>>>>> Ajax
>> >>>>>>>> examples and pre built widgets I have to say I'm a little
>> puzzled!
>> >>>>>>>> Why
>> >>>>>>>> does
>> >>>>>>>> wickets core JS framework not use one of the main JS frameworks
>> >>>>>>>> that
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> are
>> >>>>>>
>> >>>>>>
>> >>>>>>>> available such as jQuery, Dojo or Prototype? I believe you have
>> a
>> >>>>>>>> hand
>> >>>>>>>> rolled version of mootools (although I may be wrong). Do the
>> Wicket
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> core
>> >>>>>>
>> >>>>>>
>> >>>>>>>> team plan on supporting and enriching this hand rolled framework
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> alone?
>> >>>>>>
>> >>>>>>
>> >>>>>>>> Surely it would make more sense to choose one of the main JS
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> frameworks
>> >>>>>>
>> >>>>>>
>> >>>>>>>> that
>> >>>>>>>> have dedicated teams of devs supporting it?
>> >>>>>>>>
>> >>>>>>>> Also I've found that Ajax widgets in wicket seem quite "here and
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> there"
>> >>>>>>
>> >>>>>>
>> >>>>>>>> in
>> >>>>>>>> their implementation. Some demos use prototype, some use YUI (a
>> >>>>>>>> datepicker
>> >>>>>>>> for example). Doesnt this go against what JS frameworks are
>> trying
>> >>>>>>>> to
>> >>>>>>>> provide? Choosing a decent framework such as jQuery or Prototype
>> >>>>>>>> will
>> >>>>>>>> give
>> >>>>>>>> the developer a solid toolkit on which they can build, so extra
>> >>>>>>>> components
>> >>>>>>>> such as datepickers or custom widgets can be applied as
>> "Plugins".
>> >>>>>>>> Sticking
>> >>>>>>>> to one framework reduces hits to the server, bandwidth, load and
>> >>>>>>>> processing
>> >>>>>>>> times all of which imho are good things.
>> >>>>>>>>
>> >>>>>>>> My worry at the moment is that the demos in wicket are very
>> "lets
>> >>>>>>>> get
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> it
>> >>>>>>
>> >>>>>>
>> >>>>>>>> working on the frontend" and not "lets think about a framework
>> and
>> >>>>>>>> its
>> >>>>>>>> rich
>> >>>>>>>> functionality".
>> >>>>>>>>
>> >>>>>>>> SO to summarize :) are there any thoughts about using a single,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>> supported
>> >>>>>>
>> >>>>>>
>> >>>>>>>> framework in wicket and moving forward from there?
>> >>>>>>>>
>> >>>>>>>> Cheers,
>> >>>>>>>>
>> >>>>>>>> Ben
>> >>>>>>>> --
>> >>>>>>>> View this message in context:
>> >>>>>>>>
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>> >>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> --
>> >>>>>> View this message in context:
>> >>>>>>
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>> >>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496854
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12518272
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Johan Compagner <jc...@gmail.com>.
ahh so you want to do real programming in the javascript?
So attaching purely in client side javascript events and those events call
the server?
Thats not how wicket works, in wicket you normally don't program javascript
you get it pushed
and the events get attached by the serverside.
johan
On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>
>
> Sorry,
>
> Again mine is coming from a very front end perspective ie writing JS in a
> progressive enhancement style.
>
> Your pseudo code looks like the other end of the spectrum ie java code
>
> My main point over this thread was to also appreciate that while wicket is
> designed for java devs it needs to have JS framework code that can be used
> by UI developers.
>
> Hence why I believe having the ability to write things in a front end way
> is
> a GOOD thing.
>
>
>
> Nino Saturnino Martinez Vazquez Wael wrote:
> >
> > hmm I'll have to take a deeper look into this.
> >
> > The main idea about the input events are that you should be able to just
> > add events of any sort (mouse, key, time?) to anycomponent that will
> > either trigger that component or another, this means triggering from
> > client to server. No real work has been done on the input events project
> > other that the project are setup on the stuff svn, also some base
> > infrastructure has been done.
> >
> > pseudo code example:
> >
> > form myform;
> >
> > label.add(new Event(Events.keypressed(a),Event.keydown, myform));
> >
> > above should trigger myform when a are pressed and label has focus.
> >
> > disclaimer : this might be bad example:)
> >
> > regards Nino
> >
> > bmarvell wrote:
> >> I personally think a CSS DOM traversal/manipulation model that can tie
> to
> >> events elegantly is what's needed.
> >>
> >> i.e:
> >>
> >> http://jquery.com
> >>
> >> http://bennolan.com/behaviour/
> >>
> >> Being able to say:
> >>
> >> $("#somthing li").click(.....
> >>
> >> Is so much easier to code and read than:
> >>
> >> document.getElementById
> ("something").getElementsByTagName("li")..........
> >>
> >>
> >> Nino Saturnino Martinez Vazquez Wael wrote:
> >>
> >>> on the Events part I might aswell go on with the input events
> contrib...
> >>> As this now has been up a lot of times one the mailing list..
> >>>
> >>> I might seem to find some time to do it..
> >>>
> >>> But it would be really nice to see what people would like of features
> >>> from it?
> >>>
> >>> regards Nino
> >>>
> >>> bmarvell wrote:
> >>>
> >>>> Right then so for completeness:
> >>>>
> >>>> * Ajax Calls [In house]
> >>>> * Animation [animator.js]
> >>>> * Dom manipulation and traversal (CSS style for this is becoming
> highly
> >>>> favourable) [??]
> >>>> * Events [??]
> >>>>
> >>>> Has any of this been addressed or considered yet?
> >>>>
> >>>> I'm just coming in from the point of a front end developer and trying
> >>>> to
> >>>> identify whats either missing or I cant find :confused:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Gerolf Seitz wrote:
> >>>>
> >>>>
> >>>>>> So for those specific issues are we to say:
> >>>>>>
> >>>>>>
> >>>>>>
> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
> >>>>>>
> >>>>>> Is the future??
> >>>>>>
> >>>>>>
> >>>>> in this case, take a look at
> >>>>>
> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
> >>>>> ;)
> >>>>>
> >>>>> gerolf
> >>>>>
> >>>>> Matej Knopp-2 wrote:
> >>>>>
> >>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> this question has been asked here numerous times. The thing is,
> >>>>>>> there
> >>>>>>> is in fact no real alternative of wicket-ajax for us.
> >>>>>>>
> >>>>>>> Wicket is not built about Ajax widgets.Wicket is about server-side
> >>>>>>> components that can be partially updated using Ajax. That's a
> >>>>>>> fundamental difference.
> >>>>>>>
> >>>>>>> As for the features, wicket-ajax has numerous advanced features
> such
> >>>>>>> as
> >>>>>>> - asynchronous pipeline that allows loading dependencies in
> >>>>>>> asynchronous way, yet respecting the order (unlike e.g. dojo where
> >>>>>>> the
> >>>>>>> depending javascript are loaded using synchronous http requests
> >>>>>>> which
> >>>>>>> block entire browser = usability disaster)
> >>>>>>> - ajax channels that allow you to stack or drop pending requests
> >>>>>>> - multipart ajax response for replacing multiple components in one
> >>>>>>> response, ajax header contribution processing (so that component
> can
> >>>>>>> render header response as it would normally do, wicket
> transparently
> >>>>>>> processes it and loads all dependencies (javascript references,
> >>>>>>> stylesheets, etc) in an asynchronous way while respecting the
> order)
> >>>>>>> - wicket-ajax.js is about 7kb compressed (with stripped down
> >>>>>>> comments). As this is a general purpose ajax framework, the size
> >>>>>>> matters. For sites where you using ajax only on certain places,
> >>>>>>> having
> >>>>>>> a 200kb javascript dependency would be quite a burden
> >>>>>>> - there's more to it, the code is quite well documented, if you
> are
> >>>>>>> interested you can dig into it, also you should search achives,
> this
> >>>>>>> has been discussed here already.
> >>>>>>>
> >>>>>>> -Matej
> >>>>>>>
> >>>>>>>
> >>>>>>> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hello all,
> >>>>>>>>
> >>>>>>>> This is my first post so please be gentle ;)
> >>>>>>>>
> >>>>>>>> I'm a user interface developer (no Java) working on what will
> >>>>>>>>
> >>>>>>>>
> >>>>>> inevitably
> >>>>>>
> >>>>>>
> >>>>>>>> be
> >>>>>>>> a fairly heavy Ajax wicket project. After looking at a number of
> >>>>>>>> Ajax
> >>>>>>>> examples and pre built widgets I have to say I'm a little
> puzzled!
> >>>>>>>> Why
> >>>>>>>> does
> >>>>>>>> wickets core JS framework not use one of the main JS frameworks
> >>>>>>>> that
> >>>>>>>>
> >>>>>>>>
> >>>>>> are
> >>>>>>
> >>>>>>
> >>>>>>>> available such as jQuery, Dojo or Prototype? I believe you have a
> >>>>>>>> hand
> >>>>>>>> rolled version of mootools (although I may be wrong). Do the
> Wicket
> >>>>>>>>
> >>>>>>>>
> >>>>>> core
> >>>>>>
> >>>>>>
> >>>>>>>> team plan on supporting and enriching this hand rolled framework
> >>>>>>>>
> >>>>>>>>
> >>>>>> alone?
> >>>>>>
> >>>>>>
> >>>>>>>> Surely it would make more sense to choose one of the main JS
> >>>>>>>>
> >>>>>>>>
> >>>>>> frameworks
> >>>>>>
> >>>>>>
> >>>>>>>> that
> >>>>>>>> have dedicated teams of devs supporting it?
> >>>>>>>>
> >>>>>>>> Also I've found that Ajax widgets in wicket seem quite "here and
> >>>>>>>>
> >>>>>>>>
> >>>>>> there"
> >>>>>>
> >>>>>>
> >>>>>>>> in
> >>>>>>>> their implementation. Some demos use prototype, some use YUI (a
> >>>>>>>> datepicker
> >>>>>>>> for example). Doesnt this go against what JS frameworks are
> trying
> >>>>>>>> to
> >>>>>>>> provide? Choosing a decent framework such as jQuery or Prototype
> >>>>>>>> will
> >>>>>>>> give
> >>>>>>>> the developer a solid toolkit on which they can build, so extra
> >>>>>>>> components
> >>>>>>>> such as datepickers or custom widgets can be applied as
> "Plugins".
> >>>>>>>> Sticking
> >>>>>>>> to one framework reduces hits to the server, bandwidth, load and
> >>>>>>>> processing
> >>>>>>>> times all of which imho are good things.
> >>>>>>>>
> >>>>>>>> My worry at the moment is that the demos in wicket are very "lets
> >>>>>>>> get
> >>>>>>>>
> >>>>>>>>
> >>>>>> it
> >>>>>>
> >>>>>>
> >>>>>>>> working on the frontend" and not "lets think about a framework
> and
> >>>>>>>> its
> >>>>>>>> rich
> >>>>>>>> functionality".
> >>>>>>>>
> >>>>>>>> SO to summarize :) are there any thoughts about using a single,
> >>>>>>>>
> >>>>>>>>
> >>>>>> supported
> >>>>>>
> >>>>>>
> >>>>>>>> framework in wicket and moving forward from there?
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>>
> >>>>>>>> Ben
> >>>>>>>> --
> >>>>>>>> View this message in context:
> >>>>>>>>
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> >>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>>
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
> >>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496854
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: JavaScript Frameworks
Posted by William Hoover <wh...@nemours.org>.
+1
-----Original Message-----
From: bmarvell [mailto:madmarv187@gmail.com]
Sent: Wednesday, September 05, 2007 8:19 AM
To: users@wicket.apache.org
Subject: Re: JavaScript Frameworks
Sorry,
Again mine is coming from a very front end perspective ie writing JS in a
progressive enhancement style.
Your pseudo code looks like the other end of the spectrum ie java code
My main point over this thread was to also appreciate that while wicket is
designed for java devs it needs to have JS framework code that can be used
by UI developers.
Hence why I believe having the ability to write things in a front end way is
a GOOD thing.
Nino Saturnino Martinez Vazquez Wael wrote:
>
> hmm I'll have to take a deeper look into this.
>
> The main idea about the input events are that you should be able to just
> add events of any sort (mouse, key, time?) to anycomponent that will
> either trigger that component or another, this means triggering from
> client to server. No real work has been done on the input events project
> other that the project are setup on the stuff svn, also some base
> infrastructure has been done.
>
> pseudo code example:
>
> form myform;
>
> label.add(new Event(Events.keypressed(a),Event.keydown, myform));
>
> above should trigger myform when a are pressed and label has focus.
>
> disclaimer : this might be bad example:)
>
> regards Nino
>
> bmarvell wrote:
>> I personally think a CSS DOM traversal/manipulation model that can tie to
>> events elegantly is what's needed.
>>
>> i.e:
>>
>> http://jquery.com
>>
>> http://bennolan.com/behaviour/
>>
>> Being able to say:
>>
>> $("#somthing li").click(.....
>>
>> Is so much easier to code and read than:
>>
>> document.getElementById("something").getElementsByTagName("li")..........
>>
>>
>> Nino Saturnino Martinez Vazquez Wael wrote:
>>
>>> on the Events part I might aswell go on with the input events contrib...
>>> As this now has been up a lot of times one the mailing list..
>>>
>>> I might seem to find some time to do it..
>>>
>>> But it would be really nice to see what people would like of features
>>> from it?
>>>
>>> regards Nino
>>>
>>> bmarvell wrote:
>>>
>>>> Right then so for completeness:
>>>>
>>>> * Ajax Calls [In house]
>>>> * Animation [animator.js]
>>>> * Dom manipulation and traversal (CSS style for this is becoming highly
>>>> favourable) [??]
>>>> * Events [??]
>>>>
>>>> Has any of this been addressed or considered yet?
>>>>
>>>> I'm just coming in from the point of a front end developer and trying
>>>> to
>>>> identify whats either missing or I cant find :confused:
>>>>
>>>>
>>>>
>>>>
>>>> Gerolf Seitz wrote:
>>>>
>>>>
>>>>>> So for those specific issues are we to say:
>>>>>>
>>>>>>
>>>>>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>>>>>>
>>>>>> Is the future??
>>>>>>
>>>>>>
>>>>> in this case, take a look at
>>>>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
>>>>> ;)
>>>>>
>>>>> gerolf
>>>>>
>>>>> Matej Knopp-2 wrote:
>>>>>
>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> this question has been asked here numerous times. The thing is,
>>>>>>> there
>>>>>>> is in fact no real alternative of wicket-ajax for us.
>>>>>>>
>>>>>>> Wicket is not built about Ajax widgets.Wicket is about server-side
>>>>>>> components that can be partially updated using Ajax. That's a
>>>>>>> fundamental difference.
>>>>>>>
>>>>>>> As for the features, wicket-ajax has numerous advanced features such
>>>>>>> as
>>>>>>> - asynchronous pipeline that allows loading dependencies in
>>>>>>> asynchronous way, yet respecting the order (unlike e.g. dojo where
>>>>>>> the
>>>>>>> depending javascript are loaded using synchronous http requests
>>>>>>> which
>>>>>>> block entire browser = usability disaster)
>>>>>>> - ajax channels that allow you to stack or drop pending requests
>>>>>>> - multipart ajax response for replacing multiple components in one
>>>>>>> response, ajax header contribution processing (so that component can
>>>>>>> render header response as it would normally do, wicket transparently
>>>>>>> processes it and loads all dependencies (javascript references,
>>>>>>> stylesheets, etc) in an asynchronous way while respecting the order)
>>>>>>> - wicket-ajax.js is about 7kb compressed (with stripped down
>>>>>>> comments). As this is a general purpose ajax framework, the size
>>>>>>> matters. For sites where you using ajax only on certain places,
>>>>>>> having
>>>>>>> a 200kb javascript dependency would be quite a burden
>>>>>>> - there's more to it, the code is quite well documented, if you are
>>>>>>> interested you can dig into it, also you should search achives, this
>>>>>>> has been discussed here already.
>>>>>>>
>>>>>>> -Matej
>>>>>>>
>>>>>>>
>>>>>>> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is my first post so please be gentle ;)
>>>>>>>>
>>>>>>>> I'm a user interface developer (no Java) working on what will
>>>>>>>>
>>>>>>>>
>>>>>> inevitably
>>>>>>
>>>>>>
>>>>>>>> be
>>>>>>>> a fairly heavy Ajax wicket project. After looking at a number of
>>>>>>>> Ajax
>>>>>>>> examples and pre built widgets I have to say I'm a little puzzled!
>>>>>>>> Why
>>>>>>>> does
>>>>>>>> wickets core JS framework not use one of the main JS frameworks
>>>>>>>> that
>>>>>>>>
>>>>>>>>
>>>>>> are
>>>>>>
>>>>>>
>>>>>>>> available such as jQuery, Dojo or Prototype? I believe you have a
>>>>>>>> hand
>>>>>>>> rolled version of mootools (although I may be wrong). Do the Wicket
>>>>>>>>
>>>>>>>>
>>>>>> core
>>>>>>
>>>>>>
>>>>>>>> team plan on supporting and enriching this hand rolled framework
>>>>>>>>
>>>>>>>>
>>>>>> alone?
>>>>>>
>>>>>>
>>>>>>>> Surely it would make more sense to choose one of the main JS
>>>>>>>>
>>>>>>>>
>>>>>> frameworks
>>>>>>
>>>>>>
>>>>>>>> that
>>>>>>>> have dedicated teams of devs supporting it?
>>>>>>>>
>>>>>>>> Also I've found that Ajax widgets in wicket seem quite "here and
>>>>>>>>
>>>>>>>>
>>>>>> there"
>>>>>>
>>>>>>
>>>>>>>> in
>>>>>>>> their implementation. Some demos use prototype, some use YUI (a
>>>>>>>> datepicker
>>>>>>>> for example). Doesnt this go against what JS frameworks are trying
>>>>>>>> to
>>>>>>>> provide? Choosing a decent framework such as jQuery or Prototype
>>>>>>>> will
>>>>>>>> give
>>>>>>>> the developer a solid toolkit on which they can build, so extra
>>>>>>>> components
>>>>>>>> such as datepickers or custom widgets can be applied as "Plugins".
>>>>>>>> Sticking
>>>>>>>> to one framework reduces hits to the server, bandwidth, load and
>>>>>>>> processing
>>>>>>>> times all of which imho are good things.
>>>>>>>>
>>>>>>>> My worry at the moment is that the demos in wicket are very "lets
>>>>>>>> get
>>>>>>>>
>>>>>>>>
>>>>>> it
>>>>>>
>>>>>>
>>>>>>>> working on the frontend" and not "lets think about a framework and
>>>>>>>> its
>>>>>>>> rich
>>>>>>>> functionality".
>>>>>>>>
>>>>>>>> SO to summarize :) are there any thoughts about using a single,
>>>>>>>>
>>>>>>>>
>>>>>> supported
>>>>>>
>>>>>>
>>>>>>>> framework in wicket and moving forward from there?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Ben
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496854
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by bmarvell <ma...@gmail.com>.
Sorry,
Again mine is coming from a very front end perspective ie writing JS in a
progressive enhancement style.
Your pseudo code looks like the other end of the spectrum ie java code
My main point over this thread was to also appreciate that while wicket is
designed for java devs it needs to have JS framework code that can be used
by UI developers.
Hence why I believe having the ability to write things in a front end way is
a GOOD thing.
Nino Saturnino Martinez Vazquez Wael wrote:
>
> hmm I'll have to take a deeper look into this.
>
> The main idea about the input events are that you should be able to just
> add events of any sort (mouse, key, time?) to anycomponent that will
> either trigger that component or another, this means triggering from
> client to server. No real work has been done on the input events project
> other that the project are setup on the stuff svn, also some base
> infrastructure has been done.
>
> pseudo code example:
>
> form myform;
>
> label.add(new Event(Events.keypressed(a),Event.keydown, myform));
>
> above should trigger myform when a are pressed and label has focus.
>
> disclaimer : this might be bad example:)
>
> regards Nino
>
> bmarvell wrote:
>> I personally think a CSS DOM traversal/manipulation model that can tie to
>> events elegantly is what's needed.
>>
>> i.e:
>>
>> http://jquery.com
>>
>> http://bennolan.com/behaviour/
>>
>> Being able to say:
>>
>> $("#somthing li").click(.....
>>
>> Is so much easier to code and read than:
>>
>> document.getElementById("something").getElementsByTagName("li")..........
>>
>>
>> Nino Saturnino Martinez Vazquez Wael wrote:
>>
>>> on the Events part I might aswell go on with the input events contrib...
>>> As this now has been up a lot of times one the mailing list..
>>>
>>> I might seem to find some time to do it..
>>>
>>> But it would be really nice to see what people would like of features
>>> from it?
>>>
>>> regards Nino
>>>
>>> bmarvell wrote:
>>>
>>>> Right then so for completeness:
>>>>
>>>> * Ajax Calls [In house]
>>>> * Animation [animator.js]
>>>> * Dom manipulation and traversal (CSS style for this is becoming highly
>>>> favourable) [??]
>>>> * Events [??]
>>>>
>>>> Has any of this been addressed or considered yet?
>>>>
>>>> I'm just coming in from the point of a front end developer and trying
>>>> to
>>>> identify whats either missing or I cant find :confused:
>>>>
>>>>
>>>>
>>>>
>>>> Gerolf Seitz wrote:
>>>>
>>>>
>>>>>> So for those specific issues are we to say:
>>>>>>
>>>>>>
>>>>>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>>>>>>
>>>>>> Is the future??
>>>>>>
>>>>>>
>>>>> in this case, take a look at
>>>>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
>>>>> ;)
>>>>>
>>>>> gerolf
>>>>>
>>>>> Matej Knopp-2 wrote:
>>>>>
>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> this question has been asked here numerous times. The thing is,
>>>>>>> there
>>>>>>> is in fact no real alternative of wicket-ajax for us.
>>>>>>>
>>>>>>> Wicket is not built about Ajax widgets.Wicket is about server-side
>>>>>>> components that can be partially updated using Ajax. That's a
>>>>>>> fundamental difference.
>>>>>>>
>>>>>>> As for the features, wicket-ajax has numerous advanced features such
>>>>>>> as
>>>>>>> - asynchronous pipeline that allows loading dependencies in
>>>>>>> asynchronous way, yet respecting the order (unlike e.g. dojo where
>>>>>>> the
>>>>>>> depending javascript are loaded using synchronous http requests
>>>>>>> which
>>>>>>> block entire browser = usability disaster)
>>>>>>> - ajax channels that allow you to stack or drop pending requests
>>>>>>> - multipart ajax response for replacing multiple components in one
>>>>>>> response, ajax header contribution processing (so that component can
>>>>>>> render header response as it would normally do, wicket transparently
>>>>>>> processes it and loads all dependencies (javascript references,
>>>>>>> stylesheets, etc) in an asynchronous way while respecting the order)
>>>>>>> - wicket-ajax.js is about 7kb compressed (with stripped down
>>>>>>> comments). As this is a general purpose ajax framework, the size
>>>>>>> matters. For sites where you using ajax only on certain places,
>>>>>>> having
>>>>>>> a 200kb javascript dependency would be quite a burden
>>>>>>> - there's more to it, the code is quite well documented, if you are
>>>>>>> interested you can dig into it, also you should search achives, this
>>>>>>> has been discussed here already.
>>>>>>>
>>>>>>> -Matej
>>>>>>>
>>>>>>>
>>>>>>> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is my first post so please be gentle ;)
>>>>>>>>
>>>>>>>> I'm a user interface developer (no Java) working on what will
>>>>>>>>
>>>>>>>>
>>>>>> inevitably
>>>>>>
>>>>>>
>>>>>>>> be
>>>>>>>> a fairly heavy Ajax wicket project. After looking at a number of
>>>>>>>> Ajax
>>>>>>>> examples and pre built widgets I have to say I'm a little puzzled!
>>>>>>>> Why
>>>>>>>> does
>>>>>>>> wickets core JS framework not use one of the main JS frameworks
>>>>>>>> that
>>>>>>>>
>>>>>>>>
>>>>>> are
>>>>>>
>>>>>>
>>>>>>>> available such as jQuery, Dojo or Prototype? I believe you have a
>>>>>>>> hand
>>>>>>>> rolled version of mootools (although I may be wrong). Do the Wicket
>>>>>>>>
>>>>>>>>
>>>>>> core
>>>>>>
>>>>>>
>>>>>>>> team plan on supporting and enriching this hand rolled framework
>>>>>>>>
>>>>>>>>
>>>>>> alone?
>>>>>>
>>>>>>
>>>>>>>> Surely it would make more sense to choose one of the main JS
>>>>>>>>
>>>>>>>>
>>>>>> frameworks
>>>>>>
>>>>>>
>>>>>>>> that
>>>>>>>> have dedicated teams of devs supporting it?
>>>>>>>>
>>>>>>>> Also I've found that Ajax widgets in wicket seem quite "here and
>>>>>>>>
>>>>>>>>
>>>>>> there"
>>>>>>
>>>>>>
>>>>>>>> in
>>>>>>>> their implementation. Some demos use prototype, some use YUI (a
>>>>>>>> datepicker
>>>>>>>> for example). Doesnt this go against what JS frameworks are trying
>>>>>>>> to
>>>>>>>> provide? Choosing a decent framework such as jQuery or Prototype
>>>>>>>> will
>>>>>>>> give
>>>>>>>> the developer a solid toolkit on which they can build, so extra
>>>>>>>> components
>>>>>>>> such as datepickers or custom widgets can be applied as "Plugins".
>>>>>>>> Sticking
>>>>>>>> to one framework reduces hits to the server, bandwidth, load and
>>>>>>>> processing
>>>>>>>> times all of which imho are good things.
>>>>>>>>
>>>>>>>> My worry at the moment is that the demos in wicket are very "lets
>>>>>>>> get
>>>>>>>>
>>>>>>>>
>>>>>> it
>>>>>>
>>>>>>
>>>>>>>> working on the frontend" and not "lets think about a framework and
>>>>>>>> its
>>>>>>>> rich
>>>>>>>> functionality".
>>>>>>>>
>>>>>>>> SO to summarize :) are there any thoughts about using a single,
>>>>>>>>
>>>>>>>>
>>>>>> supported
>>>>>>
>>>>>>
>>>>>>>> framework in wicket and moving forward from there?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Ben
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496854
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
hmm I'll have to take a deeper look into this.
The main idea about the input events are that you should be able to just
add events of any sort (mouse, key, time?) to anycomponent that will
either trigger that component or another, this means triggering from
client to server. No real work has been done on the input events project
other that the project are setup on the stuff svn, also some base
infrastructure has been done.
pseudo code example:
form myform;
label.add(new Event(Events.keypressed(a),Event.keydown, myform));
above should trigger myform when a are pressed and label has focus.
disclaimer : this might be bad example:)
regards Nino
bmarvell wrote:
> I personally think a CSS DOM traversal/manipulation model that can tie to
> events elegantly is what's needed.
>
> i.e:
>
> http://jquery.com
>
> http://bennolan.com/behaviour/
>
> Being able to say:
>
> $("#somthing li").click(.....
>
> Is so much easier to code and read than:
>
> document.getElementById("something").getElementsByTagName("li")..........
>
>
> Nino Saturnino Martinez Vazquez Wael wrote:
>
>> on the Events part I might aswell go on with the input events contrib...
>> As this now has been up a lot of times one the mailing list..
>>
>> I might seem to find some time to do it..
>>
>> But it would be really nice to see what people would like of features
>> from it?
>>
>> regards Nino
>>
>> bmarvell wrote:
>>
>>> Right then so for completeness:
>>>
>>> * Ajax Calls [In house]
>>> * Animation [animator.js]
>>> * Dom manipulation and traversal (CSS style for this is becoming highly
>>> favourable) [??]
>>> * Events [??]
>>>
>>> Has any of this been addressed or considered yet?
>>>
>>> I'm just coming in from the point of a front end developer and trying to
>>> identify whats either missing or I cant find :confused:
>>>
>>>
>>>
>>>
>>> Gerolf Seitz wrote:
>>>
>>>
>>>>> So for those specific issues are we to say:
>>>>>
>>>>>
>>>>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>>>>>
>>>>> Is the future??
>>>>>
>>>>>
>>>> in this case, take a look at
>>>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
>>>> ;)
>>>>
>>>> gerolf
>>>>
>>>> Matej Knopp-2 wrote:
>>>>
>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this question has been asked here numerous times. The thing is, there
>>>>>> is in fact no real alternative of wicket-ajax for us.
>>>>>>
>>>>>> Wicket is not built about Ajax widgets.Wicket is about server-side
>>>>>> components that can be partially updated using Ajax. That's a
>>>>>> fundamental difference.
>>>>>>
>>>>>> As for the features, wicket-ajax has numerous advanced features such
>>>>>> as
>>>>>> - asynchronous pipeline that allows loading dependencies in
>>>>>> asynchronous way, yet respecting the order (unlike e.g. dojo where the
>>>>>> depending javascript are loaded using synchronous http requests which
>>>>>> block entire browser = usability disaster)
>>>>>> - ajax channels that allow you to stack or drop pending requests
>>>>>> - multipart ajax response for replacing multiple components in one
>>>>>> response, ajax header contribution processing (so that component can
>>>>>> render header response as it would normally do, wicket transparently
>>>>>> processes it and loads all dependencies (javascript references,
>>>>>> stylesheets, etc) in an asynchronous way while respecting the order)
>>>>>> - wicket-ajax.js is about 7kb compressed (with stripped down
>>>>>> comments). As this is a general purpose ajax framework, the size
>>>>>> matters. For sites where you using ajax only on certain places, having
>>>>>> a 200kb javascript dependency would be quite a burden
>>>>>> - there's more to it, the code is quite well documented, if you are
>>>>>> interested you can dig into it, also you should search achives, this
>>>>>> has been discussed here already.
>>>>>>
>>>>>> -Matej
>>>>>>
>>>>>>
>>>>>> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> This is my first post so please be gentle ;)
>>>>>>>
>>>>>>> I'm a user interface developer (no Java) working on what will
>>>>>>>
>>>>>>>
>>>>> inevitably
>>>>>
>>>>>
>>>>>>> be
>>>>>>> a fairly heavy Ajax wicket project. After looking at a number of Ajax
>>>>>>> examples and pre built widgets I have to say I'm a little puzzled!
>>>>>>> Why
>>>>>>> does
>>>>>>> wickets core JS framework not use one of the main JS frameworks that
>>>>>>>
>>>>>>>
>>>>> are
>>>>>
>>>>>
>>>>>>> available such as jQuery, Dojo or Prototype? I believe you have a
>>>>>>> hand
>>>>>>> rolled version of mootools (although I may be wrong). Do the Wicket
>>>>>>>
>>>>>>>
>>>>> core
>>>>>
>>>>>
>>>>>>> team plan on supporting and enriching this hand rolled framework
>>>>>>>
>>>>>>>
>>>>> alone?
>>>>>
>>>>>
>>>>>>> Surely it would make more sense to choose one of the main JS
>>>>>>>
>>>>>>>
>>>>> frameworks
>>>>>
>>>>>
>>>>>>> that
>>>>>>> have dedicated teams of devs supporting it?
>>>>>>>
>>>>>>> Also I've found that Ajax widgets in wicket seem quite "here and
>>>>>>>
>>>>>>>
>>>>> there"
>>>>>
>>>>>
>>>>>>> in
>>>>>>> their implementation. Some demos use prototype, some use YUI (a
>>>>>>> datepicker
>>>>>>> for example). Doesnt this go against what JS frameworks are trying to
>>>>>>> provide? Choosing a decent framework such as jQuery or Prototype will
>>>>>>> give
>>>>>>> the developer a solid toolkit on which they can build, so extra
>>>>>>> components
>>>>>>> such as datepickers or custom widgets can be applied as "Plugins".
>>>>>>> Sticking
>>>>>>> to one framework reduces hits to the server, bandwidth, load and
>>>>>>> processing
>>>>>>> times all of which imho are good things.
>>>>>>>
>>>>>>> My worry at the moment is that the demos in wicket are very "lets get
>>>>>>>
>>>>>>>
>>>>> it
>>>>>
>>>>>
>>>>>>> working on the frontend" and not "lets think about a framework and
>>>>>>> its
>>>>>>> rich
>>>>>>> functionality".
>>>>>>>
>>>>>>> SO to summarize :) are there any thoughts about using a single,
>>>>>>>
>>>>>>>
>>>>> supported
>>>>>
>>>>>
>>>>>>> framework in wicket and moving forward from there?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Ben
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by bmarvell <ma...@gmail.com>.
I personally think a CSS DOM traversal/manipulation model that can tie to
events elegantly is what's needed.
i.e:
http://jquery.com
http://bennolan.com/behaviour/
Being able to say:
$("#somthing li").click(.....
Is so much easier to code and read than:
document.getElementById("something").getElementsByTagName("li")..........
Nino Saturnino Martinez Vazquez Wael wrote:
>
> on the Events part I might aswell go on with the input events contrib...
> As this now has been up a lot of times one the mailing list..
>
> I might seem to find some time to do it..
>
> But it would be really nice to see what people would like of features
> from it?
>
> regards Nino
>
> bmarvell wrote:
>> Right then so for completeness:
>>
>> * Ajax Calls [In house]
>> * Animation [animator.js]
>> * Dom manipulation and traversal (CSS style for this is becoming highly
>> favourable) [??]
>> * Events [??]
>>
>> Has any of this been addressed or considered yet?
>>
>> I'm just coming in from the point of a front end developer and trying to
>> identify whats either missing or I cant find :confused:
>>
>>
>>
>>
>> Gerolf Seitz wrote:
>>
>>>> So for those specific issues are we to say:
>>>>
>>>>
>>>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>>>>
>>>> Is the future??
>>>>
>>> in this case, take a look at
>>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
>>> ;)
>>>
>>> gerolf
>>>
>>> Matej Knopp-2 wrote:
>>>
>>>>> Hi,
>>>>>
>>>>> this question has been asked here numerous times. The thing is, there
>>>>> is in fact no real alternative of wicket-ajax for us.
>>>>>
>>>>> Wicket is not built about Ajax widgets.Wicket is about server-side
>>>>> components that can be partially updated using Ajax. That's a
>>>>> fundamental difference.
>>>>>
>>>>> As for the features, wicket-ajax has numerous advanced features such
>>>>> as
>>>>> - asynchronous pipeline that allows loading dependencies in
>>>>> asynchronous way, yet respecting the order (unlike e.g. dojo where the
>>>>> depending javascript are loaded using synchronous http requests which
>>>>> block entire browser = usability disaster)
>>>>> - ajax channels that allow you to stack or drop pending requests
>>>>> - multipart ajax response for replacing multiple components in one
>>>>> response, ajax header contribution processing (so that component can
>>>>> render header response as it would normally do, wicket transparently
>>>>> processes it and loads all dependencies (javascript references,
>>>>> stylesheets, etc) in an asynchronous way while respecting the order)
>>>>> - wicket-ajax.js is about 7kb compressed (with stripped down
>>>>> comments). As this is a general purpose ajax framework, the size
>>>>> matters. For sites where you using ajax only on certain places, having
>>>>> a 200kb javascript dependency would be quite a burden
>>>>> - there's more to it, the code is quite well documented, if you are
>>>>> interested you can dig into it, also you should search achives, this
>>>>> has been discussed here already.
>>>>>
>>>>> -Matej
>>>>>
>>>>>
>>>>> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> This is my first post so please be gentle ;)
>>>>>>
>>>>>> I'm a user interface developer (no Java) working on what will
>>>>>>
>>>> inevitably
>>>>
>>>>>> be
>>>>>> a fairly heavy Ajax wicket project. After looking at a number of Ajax
>>>>>> examples and pre built widgets I have to say I'm a little puzzled!
>>>>>> Why
>>>>>> does
>>>>>> wickets core JS framework not use one of the main JS frameworks that
>>>>>>
>>>> are
>>>>
>>>>>> available such as jQuery, Dojo or Prototype? I believe you have a
>>>>>> hand
>>>>>> rolled version of mootools (although I may be wrong). Do the Wicket
>>>>>>
>>>> core
>>>>
>>>>>> team plan on supporting and enriching this hand rolled framework
>>>>>>
>>>> alone?
>>>>
>>>>>> Surely it would make more sense to choose one of the main JS
>>>>>>
>>>> frameworks
>>>>
>>>>>> that
>>>>>> have dedicated teams of devs supporting it?
>>>>>>
>>>>>> Also I've found that Ajax widgets in wicket seem quite "here and
>>>>>>
>>>> there"
>>>>
>>>>>> in
>>>>>> their implementation. Some demos use prototype, some use YUI (a
>>>>>> datepicker
>>>>>> for example). Doesnt this go against what JS frameworks are trying to
>>>>>> provide? Choosing a decent framework such as jQuery or Prototype will
>>>>>> give
>>>>>> the developer a solid toolkit on which they can build, so extra
>>>>>> components
>>>>>> such as datepickers or custom widgets can be applied as "Plugins".
>>>>>> Sticking
>>>>>> to one framework reduces hits to the server, bandwidth, load and
>>>>>> processing
>>>>>> times all of which imho are good things.
>>>>>>
>>>>>> My worry at the moment is that the demos in wicket are very "lets get
>>>>>>
>>>> it
>>>>
>>>>>> working on the frontend" and not "lets think about a framework and
>>>>>> its
>>>>>> rich
>>>>>> functionality".
>>>>>>
>>>>>> SO to summarize :) are there any thoughts about using a single,
>>>>>>
>>>> supported
>>>>
>>>>>> framework in wicket and moving forward from there?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ben
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496447
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
on the Events part I might aswell go on with the input events contrib...
As this now has been up a lot of times one the mailing list..
I might seem to find some time to do it..
But it would be really nice to see what people would like of features
from it?
regards Nino
bmarvell wrote:
> Right then so for completeness:
>
> * Ajax Calls [In house]
> * Animation [animator.js]
> * Dom manipulation and traversal (CSS style for this is becoming highly
> favourable) [??]
> * Events [??]
>
> Has any of this been addressed or considered yet?
>
> I'm just coming in from the point of a front end developer and trying to
> identify whats either missing or I cant find :confused:
>
>
>
>
> Gerolf Seitz wrote:
>
>>> So for those specific issues are we to say:
>>>
>>>
>>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>>>
>>> Is the future??
>>>
>> in this case, take a look at
>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
>> ;)
>>
>> gerolf
>>
>> Matej Knopp-2 wrote:
>>
>>>> Hi,
>>>>
>>>> this question has been asked here numerous times. The thing is, there
>>>> is in fact no real alternative of wicket-ajax for us.
>>>>
>>>> Wicket is not built about Ajax widgets.Wicket is about server-side
>>>> components that can be partially updated using Ajax. That's a
>>>> fundamental difference.
>>>>
>>>> As for the features, wicket-ajax has numerous advanced features such as
>>>> - asynchronous pipeline that allows loading dependencies in
>>>> asynchronous way, yet respecting the order (unlike e.g. dojo where the
>>>> depending javascript are loaded using synchronous http requests which
>>>> block entire browser = usability disaster)
>>>> - ajax channels that allow you to stack or drop pending requests
>>>> - multipart ajax response for replacing multiple components in one
>>>> response, ajax header contribution processing (so that component can
>>>> render header response as it would normally do, wicket transparently
>>>> processes it and loads all dependencies (javascript references,
>>>> stylesheets, etc) in an asynchronous way while respecting the order)
>>>> - wicket-ajax.js is about 7kb compressed (with stripped down
>>>> comments). As this is a general purpose ajax framework, the size
>>>> matters. For sites where you using ajax only on certain places, having
>>>> a 200kb javascript dependency would be quite a burden
>>>> - there's more to it, the code is quite well documented, if you are
>>>> interested you can dig into it, also you should search achives, this
>>>> has been discussed here already.
>>>>
>>>> -Matej
>>>>
>>>>
>>>> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> This is my first post so please be gentle ;)
>>>>>
>>>>> I'm a user interface developer (no Java) working on what will
>>>>>
>>> inevitably
>>>
>>>>> be
>>>>> a fairly heavy Ajax wicket project. After looking at a number of Ajax
>>>>> examples and pre built widgets I have to say I'm a little puzzled! Why
>>>>> does
>>>>> wickets core JS framework not use one of the main JS frameworks that
>>>>>
>>> are
>>>
>>>>> available such as jQuery, Dojo or Prototype? I believe you have a hand
>>>>> rolled version of mootools (although I may be wrong). Do the Wicket
>>>>>
>>> core
>>>
>>>>> team plan on supporting and enriching this hand rolled framework
>>>>>
>>> alone?
>>>
>>>>> Surely it would make more sense to choose one of the main JS
>>>>>
>>> frameworks
>>>
>>>>> that
>>>>> have dedicated teams of devs supporting it?
>>>>>
>>>>> Also I've found that Ajax widgets in wicket seem quite "here and
>>>>>
>>> there"
>>>
>>>>> in
>>>>> their implementation. Some demos use prototype, some use YUI (a
>>>>> datepicker
>>>>> for example). Doesnt this go against what JS frameworks are trying to
>>>>> provide? Choosing a decent framework such as jQuery or Prototype will
>>>>> give
>>>>> the developer a solid toolkit on which they can build, so extra
>>>>> components
>>>>> such as datepickers or custom widgets can be applied as "Plugins".
>>>>> Sticking
>>>>> to one framework reduces hits to the server, bandwidth, load and
>>>>> processing
>>>>> times all of which imho are good things.
>>>>>
>>>>> My worry at the moment is that the demos in wicket are very "lets get
>>>>>
>>> it
>>>
>>>>> working on the frontend" and not "lets think about a framework and its
>>>>> rich
>>>>> functionality".
>>>>>
>>>>> SO to summarize :) are there any thoughts about using a single,
>>>>>
>>> supported
>>>
>>>>> framework in wicket and moving forward from there?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Ben
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by bmarvell <ma...@gmail.com>.
Right then so for completeness:
* Ajax Calls [In house]
* Animation [animator.js]
* Dom manipulation and traversal (CSS style for this is becoming highly
favourable) [??]
* Events [??]
Has any of this been addressed or considered yet?
I'm just coming in from the point of a front end developer and trying to
identify whats either missing or I cant find :confused:
Gerolf Seitz wrote:
>
>>
>>
>> So for those specific issues are we to say:
>>
>>
>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>>
>> Is the future??
>
>
> in this case, take a look at
> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
> ;)
>
> gerolf
>
> Matej Knopp-2 wrote:
>> >
>> > Hi,
>> >
>> > this question has been asked here numerous times. The thing is, there
>> > is in fact no real alternative of wicket-ajax for us.
>> >
>> > Wicket is not built about Ajax widgets.Wicket is about server-side
>> > components that can be partially updated using Ajax. That's a
>> > fundamental difference.
>> >
>> > As for the features, wicket-ajax has numerous advanced features such as
>> > - asynchronous pipeline that allows loading dependencies in
>> > asynchronous way, yet respecting the order (unlike e.g. dojo where the
>> > depending javascript are loaded using synchronous http requests which
>> > block entire browser = usability disaster)
>> > - ajax channels that allow you to stack or drop pending requests
>> > - multipart ajax response for replacing multiple components in one
>> > response, ajax header contribution processing (so that component can
>> > render header response as it would normally do, wicket transparently
>> > processes it and loads all dependencies (javascript references,
>> > stylesheets, etc) in an asynchronous way while respecting the order)
>> > - wicket-ajax.js is about 7kb compressed (with stripped down
>> > comments). As this is a general purpose ajax framework, the size
>> > matters. For sites where you using ajax only on certain places, having
>> > a 200kb javascript dependency would be quite a burden
>> > - there's more to it, the code is quite well documented, if you are
>> > interested you can dig into it, also you should search achives, this
>> > has been discussed here already.
>> >
>> > -Matej
>> >
>> >
>> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>> >>
>> >> Hello all,
>> >>
>> >> This is my first post so please be gentle ;)
>> >>
>> >> I'm a user interface developer (no Java) working on what will
>> inevitably
>> >> be
>> >> a fairly heavy Ajax wicket project. After looking at a number of Ajax
>> >> examples and pre built widgets I have to say I'm a little puzzled! Why
>> >> does
>> >> wickets core JS framework not use one of the main JS frameworks that
>> are
>> >> available such as jQuery, Dojo or Prototype? I believe you have a hand
>> >> rolled version of mootools (although I may be wrong). Do the Wicket
>> core
>> >> team plan on supporting and enriching this hand rolled framework
>> alone?
>> >> Surely it would make more sense to choose one of the main JS
>> frameworks
>> >> that
>> >> have dedicated teams of devs supporting it?
>> >>
>> >> Also I've found that Ajax widgets in wicket seem quite "here and
>> there"
>> >> in
>> >> their implementation. Some demos use prototype, some use YUI (a
>> >> datepicker
>> >> for example). Doesnt this go against what JS frameworks are trying to
>> >> provide? Choosing a decent framework such as jQuery or Prototype will
>> >> give
>> >> the developer a solid toolkit on which they can build, so extra
>> >> components
>> >> such as datepickers or custom widgets can be applied as "Plugins".
>> >> Sticking
>> >> to one framework reduces hits to the server, bandwidth, load and
>> >> processing
>> >> times all of which imho are good things.
>> >>
>> >> My worry at the moment is that the demos in wicket are very "lets get
>> it
>> >> working on the frontend" and not "lets think about a framework and its
>> >> rich
>> >> functionality".
>> >>
>> >> SO to summarize :) are there any thoughts about using a single,
>> supported
>> >> framework in wicket and moving forward from there?
>> >>
>> >> Cheers,
>> >>
>> >> Ben
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495970
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Gerolf Seitz <ge...@gmail.com>.
>
>
> So for those specific issues are we to say:
>
>
> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
>
> Is the future??
in this case, take a look at
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator ;)
gerolf
Matej Knopp-2 wrote:
> >
> > Hi,
> >
> > this question has been asked here numerous times. The thing is, there
> > is in fact no real alternative of wicket-ajax for us.
> >
> > Wicket is not built about Ajax widgets.Wicket is about server-side
> > components that can be partially updated using Ajax. That's a
> > fundamental difference.
> >
> > As for the features, wicket-ajax has numerous advanced features such as
> > - asynchronous pipeline that allows loading dependencies in
> > asynchronous way, yet respecting the order (unlike e.g. dojo where the
> > depending javascript are loaded using synchronous http requests which
> > block entire browser = usability disaster)
> > - ajax channels that allow you to stack or drop pending requests
> > - multipart ajax response for replacing multiple components in one
> > response, ajax header contribution processing (so that component can
> > render header response as it would normally do, wicket transparently
> > processes it and loads all dependencies (javascript references,
> > stylesheets, etc) in an asynchronous way while respecting the order)
> > - wicket-ajax.js is about 7kb compressed (with stripped down
> > comments). As this is a general purpose ajax framework, the size
> > matters. For sites where you using ajax only on certain places, having
> > a 200kb javascript dependency would be quite a burden
> > - there's more to it, the code is quite well documented, if you are
> > interested you can dig into it, also you should search achives, this
> > has been discussed here already.
> >
> > -Matej
> >
> >
> > On 9/5/07, bmarvell <ma...@gmail.com> wrote:
> >>
> >> Hello all,
> >>
> >> This is my first post so please be gentle ;)
> >>
> >> I'm a user interface developer (no Java) working on what will
> inevitably
> >> be
> >> a fairly heavy Ajax wicket project. After looking at a number of Ajax
> >> examples and pre built widgets I have to say I'm a little puzzled! Why
> >> does
> >> wickets core JS framework not use one of the main JS frameworks that
> are
> >> available such as jQuery, Dojo or Prototype? I believe you have a hand
> >> rolled version of mootools (although I may be wrong). Do the Wicket
> core
> >> team plan on supporting and enriching this hand rolled framework alone?
> >> Surely it would make more sense to choose one of the main JS frameworks
> >> that
> >> have dedicated teams of devs supporting it?
> >>
> >> Also I've found that Ajax widgets in wicket seem quite "here and there"
> >> in
> >> their implementation. Some demos use prototype, some use YUI (a
> >> datepicker
> >> for example). Doesnt this go against what JS frameworks are trying to
> >> provide? Choosing a decent framework such as jQuery or Prototype will
> >> give
> >> the developer a solid toolkit on which they can build, so extra
> >> components
> >> such as datepickers or custom widgets can be applied as "Plugins".
> >> Sticking
> >> to one framework reduces hits to the server, bandwidth, load and
> >> processing
> >> times all of which imho are good things.
> >>
> >> My worry at the moment is that the demos in wicket are very "lets get
> it
> >> working on the frontend" and not "lets think about a framework and its
> >> rich
> >> functionality".
> >>
> >> SO to summarize :) are there any thoughts about using a single,
> supported
> >> framework in wicket and moving forward from there?
> >>
> >> Cheers,
> >>
> >> Ben
> >> --
> >> View this message in context:
> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: JavaScript Frameworks
Posted by bmarvell <ma...@gmail.com>.
Sorry if this has been asked several times but it I didn't easily find it
from a search.
Fair enough about the actual "Ajax" functionality if specific code is
required fair enough.
I was using the term Ajax in a very business sense ie: full stack
functionality; slides, fades etc.
So for those specific issues are we to say:
http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
Is the future??
Matej Knopp-2 wrote:
>
> Hi,
>
> this question has been asked here numerous times. The thing is, there
> is in fact no real alternative of wicket-ajax for us.
>
> Wicket is not built about Ajax widgets.Wicket is about server-side
> components that can be partially updated using Ajax. That's a
> fundamental difference.
>
> As for the features, wicket-ajax has numerous advanced features such as
> - asynchronous pipeline that allows loading dependencies in
> asynchronous way, yet respecting the order (unlike e.g. dojo where the
> depending javascript are loaded using synchronous http requests which
> block entire browser = usability disaster)
> - ajax channels that allow you to stack or drop pending requests
> - multipart ajax response for replacing multiple components in one
> response, ajax header contribution processing (so that component can
> render header response as it would normally do, wicket transparently
> processes it and loads all dependencies (javascript references,
> stylesheets, etc) in an asynchronous way while respecting the order)
> - wicket-ajax.js is about 7kb compressed (with stripped down
> comments). As this is a general purpose ajax framework, the size
> matters. For sites where you using ajax only on certain places, having
> a 200kb javascript dependency would be quite a burden
> - there's more to it, the code is quite well documented, if you are
> interested you can dig into it, also you should search achives, this
> has been discussed here already.
>
> -Matej
>
>
> On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>>
>> Hello all,
>>
>> This is my first post so please be gentle ;)
>>
>> I'm a user interface developer (no Java) working on what will inevitably
>> be
>> a fairly heavy Ajax wicket project. After looking at a number of Ajax
>> examples and pre built widgets I have to say I'm a little puzzled! Why
>> does
>> wickets core JS framework not use one of the main JS frameworks that are
>> available such as jQuery, Dojo or Prototype? I believe you have a hand
>> rolled version of mootools (although I may be wrong). Do the Wicket core
>> team plan on supporting and enriching this hand rolled framework alone?
>> Surely it would make more sense to choose one of the main JS frameworks
>> that
>> have dedicated teams of devs supporting it?
>>
>> Also I've found that Ajax widgets in wicket seem quite "here and there"
>> in
>> their implementation. Some demos use prototype, some use YUI (a
>> datepicker
>> for example). Doesnt this go against what JS frameworks are trying to
>> provide? Choosing a decent framework such as jQuery or Prototype will
>> give
>> the developer a solid toolkit on which they can build, so extra
>> components
>> such as datepickers or custom widgets can be applied as "Plugins".
>> Sticking
>> to one framework reduces hits to the server, bandwidth, load and
>> processing
>> times all of which imho are good things.
>>
>> My worry at the moment is that the demos in wicket are very "lets get it
>> working on the frontend" and not "lets think about a framework and its
>> rich
>> functionality".
>>
>> SO to summarize :) are there any thoughts about using a single, supported
>> framework in wicket and moving forward from there?
>>
>> Cheers,
>>
>> Ben
>> --
>> View this message in context:
>> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JavaScript Frameworks
Posted by Matej Knopp <ma...@gmail.com>.
Hi,
this question has been asked here numerous times. The thing is, there
is in fact no real alternative of wicket-ajax for us.
Wicket is not built about Ajax widgets.Wicket is about server-side
components that can be partially updated using Ajax. That's a
fundamental difference.
As for the features, wicket-ajax has numerous advanced features such as
- asynchronous pipeline that allows loading dependencies in
asynchronous way, yet respecting the order (unlike e.g. dojo where the
depending javascript are loaded using synchronous http requests which
block entire browser = usability disaster)
- ajax channels that allow you to stack or drop pending requests
- multipart ajax response for replacing multiple components in one
response, ajax header contribution processing (so that component can
render header response as it would normally do, wicket transparently
processes it and loads all dependencies (javascript references,
stylesheets, etc) in an asynchronous way while respecting the order)
- wicket-ajax.js is about 7kb compressed (with stripped down
comments). As this is a general purpose ajax framework, the size
matters. For sites where you using ajax only on certain places, having
a 200kb javascript dependency would be quite a burden
- there's more to it, the code is quite well documented, if you are
interested you can dig into it, also you should search achives, this
has been discussed here already.
-Matej
On 9/5/07, bmarvell <ma...@gmail.com> wrote:
>
> Hello all,
>
> This is my first post so please be gentle ;)
>
> I'm a user interface developer (no Java) working on what will inevitably be
> a fairly heavy Ajax wicket project. After looking at a number of Ajax
> examples and pre built widgets I have to say I'm a little puzzled! Why does
> wickets core JS framework not use one of the main JS frameworks that are
> available such as jQuery, Dojo or Prototype? I believe you have a hand
> rolled version of mootools (although I may be wrong). Do the Wicket core
> team plan on supporting and enriching this hand rolled framework alone?
> Surely it would make more sense to choose one of the main JS frameworks that
> have dedicated teams of devs supporting it?
>
> Also I've found that Ajax widgets in wicket seem quite "here and there" in
> their implementation. Some demos use prototype, some use YUI (a datepicker
> for example). Doesnt this go against what JS frameworks are trying to
> provide? Choosing a decent framework such as jQuery or Prototype will give
> the developer a solid toolkit on which they can build, so extra components
> such as datepickers or custom widgets can be applied as "Plugins". Sticking
> to one framework reduces hits to the server, bandwidth, load and processing
> times all of which imho are good things.
>
> My worry at the moment is that the demos in wicket are very "lets get it
> working on the frontend" and not "lets think about a framework and its rich
> functionality".
>
> SO to summarize :) are there any thoughts about using a single, supported
> framework in wicket and moving forward from there?
>
> Cheers,
>
> Ben
> --
> View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org