Hi,
I have created some pretty sophisticated Ajax components for a customer
project using Prototype and JQuery.
I believe client-side JavaScript is becoming more and more reliable, which
means a lot of functionality can be moved from the server side to the
client side.
When creating a sophisticated Ajax component with Wicket, the most dificult
part is to make the JavaScript code interact with the server-side models.
If Wicket would provide an abstraction layer on the JavaScript side that
would allow scripts to easily interact with a component model , then it
would be much easier to create Ajax components and behaviours, and would
probably make it possible to implement standard Wicket components in a way
that is more independent from the underlying JS framework.
Regards,
- Juliano Viana
On Mon, Sep 19, 2011 at 4:25 PM, tetsuo <[email protected]> wrote:
> Spring-JavaScript (a submodule of Spring WebFlow) used a modular approach,
> in which you could (in theory, at least) provide multiple implementations
> of
> a javascript API (
>
> http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch11s03.html
> ).
>
> You'd import the underlying library (dojo.js), the high-level library API
> (spring.js), and then the implementation of the low-level API, used by the
> high-level library (spring-dojo.js).
>
> I say in theory because they have a Dojo implementation, but never bothered
> to provide other implementations (
> https://jira.springsource.org/browse/SWF-1288)...
>
>
> Ah, one more item in the wishlist is the possibility of joining the many
> js/css resources in one big file. I think it's very hard/impossible to do
> it
> transparently (due the high granularity), but should be relatively easy if
> it required fine-tunning of the app (for example, registering all js/css
> resources to be joined/omitted in some application-wide setting).
>
> Tetsuo
>
>
> On Mon, Sep 19, 2011 at 4:03 PM, Martin Grigorov <[email protected]
> >wrote:
>
> > On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <[email protected]>
> > wrote:
> > > here is my take on the areas that need improvement:
> > >
> > > * there is a potential to significantly reduce the size of our
> > > wicket-ajax.js by rebuilding it on top of a js library like jquery
> > > which provides all the basics such as an ajax pipeline and
> > > replaceOuterHtml() function.
> > I also think that JQuery will be the best to pick at the moment, but
> > seeing what happened with Tapestry choice to use Prototype and their
> > efforts to escape from it now. Also following Node.js trends (see
> > Ender with its Jeesh (Bonzo, Bean, Qwery, ...), see CoffeeScript,
> > Underscore, all these specialized CommonJS/AMD modules) I still think
> > that picking any JS library will make some developers life harder. For
> > example if my application is based on Dojo/ExtJS/... choosing JQuery
> > will just add more some more bytes to my response ...
> > That's why I think making it with adapter with default impl based on
> > JQuery will be the best. This way Dojo users can implement the adapter
> > and be happy. Check https://github.com/balupton/History.js to see what
> > I mean.
> > > * currently we use inline attributes, eg adding a behavior to a
> > > component adds javascript in an onclick attribute. we need to switch
> > > to using dom events for this. this will solve the long outstanding
> > > problem of "cant add multiple behaviors to the same event"
> > I think adding multiple behaviors will be anti-pattern.
> > This way the user will be able to add several onclick handlers and
> > thus do several Ajax requests and this will make the processing
> > slower, especially if they are queued.
> > It will be better to have one event handler and split the work on the
> > server side.
> > > * server-side customization of callbacks is very difficult. eg it is
> > > not easy to add a callback variable that clientside js would pass to
> > > the serverside callback. this essentially requires a
> > > sql-injection-like attack on the callback url generated by wicket - so
> > > its a big hack.
> > > * ajax generates *a lot* of javascript in the source, making the
> > > document bigger. we can reduce that significantly.
> > > * better support for ajax channels and blocking behavior. eg right now
> > > its pretty hard to write an ajax button/link that blocks multiple hits
> > > or perhaps blocks all other ajax activity on the page.
> > >
> > > -igor
> > >
> > >
> > > On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <[email protected]>
> > wrote:
> > >> What is so broken about the current ajax in Wicket, that requires such
> > >> rewrite?
> > >>
> > >>
> > >>
> > >> On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <
> [email protected]
> > >wrote:
> > >>
> > >>> staged approach is fine, however its step 2 only that will cause
> > >>> migration headaches, so this is just delaying the inevitable...
> > >>>
> > >>> -igor
> > >>>
> > >>>
> > >>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <
> [email protected]
> > >
> > >>> wrote:
> > >>> > Hi,
> > >>> >
> > >>> > In the recent ticket changes by Igor I mentioned few comments that
> > >>> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever
> we
> > >>> > call it).
> > >>> >
> > >>> > I want to share my experience with trying to re-vive Matej's work
> at
> > [1],
> > >>> [2].
> > >>> > The changes there are a bit drastic (maybe because the task hasn't
> > >>> > been finished and the API breaks not cleaned) and knowing how Ajax
> > >>> > heavy are the applications I've worked on I think it will be quite
> a
> > >>> > work to migrate the apps from 1.5 to Wicket.next.
> > >>> > I also tried to introduce wicket-ajax.jar with the new impl and
> keep
> > >>> > the old one for transition but that wasn't easy too.
> > >>> >
> > >>> > So I want to propose a two step approach:
> > >>> > 1) introduce some JavaScript library for Wicket.next and improve
> > >>> > wicket-xyz.js files by using it
> > >>> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
> > >>> >
> > >>> >
> > >>> > martin-g
> > >>> >
> > >>> > 1.
> > >>>
> >
> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> > >>> > 2. https://github.com/martin-g/wicket/tree/ajax2
> > >>> >
> > >>>
> > >>
> > >
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
> >
>
