You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Vincent demay <vi...@anyware-tech.com> on 2006/11/10 17:41:47 UTC
Why rewriting js librairies
Hi,
I ask myself a question. Why wicket needs to rewrite js libraries for
ajax or other client-side scripts or to include external scripts (date
picker for exemple). There are a lot of frameworks which work fine and
do everything needed in wicket such as Dojo, script.aculo.us, etc...Why
doesn't Wicket use one of them.
--
Vincent Demay
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)561 000 649
Fax : +33 (0)561 005 146
http://www.anyware-tech.com/
Re: Why rewriting js librairies
Posted by Igor Vaynberg <ig...@gmail.com>.
On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>
> > imagine dojo provides stuff to make a conrner case like this easier.
> I used AjaxRequestTarget to construct the envelope
> and here is the client-side code. It is not perfect but it work (ie
> remove CDATA is not as clean as I wanted but I not sure is mandatory) :
your code doesnt handle encoding of cdata contents, wicket escapes any ]
chars in markup with ^] so they do not break the cdata block.
it also doesnt handle head contributions
Dojo dj_eval method do that :
looks like it takes a script fragment, but someone still needs to parse them
from regular html markup
> besides, dojo is huge - modular or not. we have something that is compact
> > and it works.
> Yes I agree with you, dojo is huge but It could help developpers to be
> more efficient, it is just my opinion. And I agree with you when you say
> that your implementation is more compact and works properly. It is very
> nice and i based my dojo development on it (AjaxRequestTarget for
> exemple).
>
well as you see we do provide adequate hooks for you to use any js lib you
want. i dont think dojo should be the default impl we depend on because we
would basically have to rewrite 90% of our javascript to work with dojo.
only 10% of wicket-ajax.js is already implemented in dojo imho - and that is
the generic xmlhttprequest wrapper.
also we would be tied to the release cycle of dojo. i dont know how often
they release, but when someone finds a bug in our js we can fix it right
away and not have to wait for dojo folks.
-igor
Re: Why rewriting js librairies
Posted by Vincent demay <vi...@anyware-tech.com>.
Igor Vaynberg a écrit :
> On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>>
>> >
>> > c) we have partial page updates of multiple components in a single
>> > request -
>> > do any of those frameworks have it? i briefly looked at ricko which
>> had
>> a
>> > similar ajax-envelope response that can encapsulate markup for
>> multiple
>> > parts of the page that need to be updated a while back - but it was
>> still
>> > very immature.
>> I wrote something like that in Wicket Dojo Contrib (DojoUpdateHandler)
>
>
> fair enough - and how much code did you have to write for that? you
> need to
> construct an xml envelope that contains markup from multiple components -
> then on javascript side you need to be able to break down that envelope,
> pull the markup out, and put it into the right places on the page. i
> wouldnt
> imagine dojo provides stuff to make a conrner case like this easier.
I used AjaxRequestTarget to construct the envelope
and here is the client-side code. It is not perfect but it work (ie
remove CDATA is not as clean as I wanted but I not sure is mandatory) :
function updateComponents(/** node */ ajaxRequest){
//get the first component in ajaxRequest
var component = dojo.dom.firstElement(ajaxRequest, "component");
var currentId;
var currentContent;
var node;
while (component != null){
currentId = component.getAttribute("id");
//get content...
currentContent = dojo.dom.innerXML(component.firstChild);
//...and remove CDATA
currentContent = currentContent.substring(9,
currentContent.length - 3);
//find the node to replace in document
node = document.getElementById(currentId);
//replace it
var range = node.ownerDocument.createRange();
range.selectNode(node);
var fragment = range.createContextualFragment(currentContent);
node.parentNode.replaceChild(fragment, node);
//get next component
component = dojo.dom.nextElement(component, "component");
}
}
>
>>
>> > d) and the biggie - header contributions. we went through a lot of
>> > pain to
>> > ensure that if you have a <script> or a <link> to js markup in the
>> _ajax_
>> > response - it will be properly executed by the browser. this is key
>> for
>> > component oriented frameworks. afaik neither dojo, nor scriptaculous,
>> nor
>> > ricko, nor anyone else out there provide this functionality.
>
>
> I understand that but a framework like dojo does not need a such
>> functionality because every script could be called by dojo.require()
>> function
>
>
> assuming that everyting is written in dojo. what about normal components
> that do include scripts they need loaded at ajax render. if something
> includes <script>alert('foo')</script> in their markup and that is made
> available through an ajax render that script needs to be executed.
> this is
> where a lot of our javascript code is, and that would have to be
> rewritten
> for dojo anyways. browsers normally wont do that if that markup is
> added via
> a dom op, so we need to do it ourselves.
Dojo dj_eval method do that :
function dj_eval(/*String*/ scriptFragment){
// summary: Perform an evaluation in the global scope. Use this
rather than calling 'eval()' directly.
// description: Placed in a separate function to minimize size of
trapped evaluation context.
// note:
// - JSC eval() takes an optional second argument which can be
'unsafe'.
// - Mozilla/SpiderMonkey eval() takes an optional second
argument which is the
// scope object for new symbols.
return dj_global.eval ? dj_global.eval(scriptFragment) :
eval(scriptFragment); // mixed
}
and this function can read distant *.js :
/**
* Reads the contents of the URI, and evaluates the contents.
* Returns true if it succeeded. Returns false if the URI reading failed.
* Throws if the evaluation throws.
* The result of the eval is not available to the caller TODO: now it
is; was this a deliberate restriction?
*
* @param uri a uri which points at the script to be loaded
* @param cb a function to process the result of evaluating the script
as an expression (optional)
*/
dojo.hostenv.loadUri = function(uri, cb /*optional*/){
if(this.loadedUris[uri]){
return 1;
}
var contents = this.getText(uri, null, true);
if(contents == null){ return 0; }
this.loadedUris[uri] = true;
if(cb){ contents = '('+contents+')'; }
var value = dj_eval(contents);
if(cb){
cb(value);
}
return 1;
}
>
> besides, dojo is huge - modular or not. we have something that is compact
> and it works.
Yes I agree with you, dojo is huge but It could help developpers to be
more efficient, it is just my opinion. And I agree with you when you say
that your implementation is more compact and works properly. It is very
nice and i based my dojo development on it (AjaxRequestTarget for exemple).
Thanks for your answer Igor
>
> -igor
>
--
Vincent
Re: Why rewriting js librairies
Posted by Igor Vaynberg <ig...@gmail.com>.
On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>
> >
> > c) we have partial page updates of multiple components in a single
> > request -
> > do any of those frameworks have it? i briefly looked at ricko which had
> a
> > similar ajax-envelope response that can encapsulate markup for multiple
> > parts of the page that need to be updated a while back - but it was
> still
> > very immature.
> I wrote something like that in Wicket Dojo Contrib (DojoUpdateHandler)
fair enough - and how much code did you have to write for that? you need to
construct an xml envelope that contains markup from multiple components -
then on javascript side you need to be able to break down that envelope,
pull the markup out, and put it into the right places on the page. i wouldnt
imagine dojo provides stuff to make a conrner case like this easier.
>
> > d) and the biggie - header contributions. we went through a lot of
> > pain to
> > ensure that if you have a <script> or a <link> to js markup in the
> _ajax_
> > response - it will be properly executed by the browser. this is key for
> > component oriented frameworks. afaik neither dojo, nor scriptaculous,
> nor
> > ricko, nor anyone else out there provide this functionality.
I understand that but a framework like dojo does not need a such
> functionality because every script could be called by dojo.require()
> function
assuming that everyting is written in dojo. what about normal components
that do include scripts they need loaded at ajax render. if something
includes <script>alert('foo')</script> in their markup and that is made
available through an ajax render that script needs to be executed. this is
where a lot of our javascript code is, and that would have to be rewritten
for dojo anyways. browsers normally wont do that if that markup is added via
a dom op, so we need to do it ourselves.
besides, dojo is huge - modular or not. we have something that is compact
and it works.
-igor
Re: Why rewriting js librairies
Posted by Vincent demay <vi...@anyware-tech.com>.
Vincent demay a écrit :
> Ok I understand that and I don't what to say that wicket dojo
> implementation is bad because it's very cool ;)
I would like to
say ajax implementation and not dojo implementation
> Indeed using a framework as is could be difficult but using it to
> develop required functionnalities could avoid to rewriting all from
> scratch.
>
> Igor Vaynberg a écrit :
>> On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>>>
>>> Hi,
>>>
>>> I ask myself a question. Why wicket needs to rewrite js libraries for
>>> ajax or other client-side scripts or to include external scripts (date
>>> picker for exemple).
>>
>>
>> we are rewriting the datepicker because our old one was not
>> compatible with
>> ASL license - and using a huge thing like dojo is silly just for a
>> datepicker.
>>
>> There are a lot of frameworks which work fine and
>>> do everything needed in wicket such as Dojo, script.aculo.us, etc...Why
>>> doesn't Wicket use one of them.
>>
>>
>> because they dont do everything that wicket does :) our ajax impl is
>> much
>> more advanced then what dojo, scriptaculous and friends provides.
>
>>
>> a) the js lib needs to be ASL compatible since it would be packaged
>> in our
>> distro
> I take dojo for example (because I know it more than the others)
> I think dojo is compatible with ASL because it's used by Cocoon
>>
>> b) we have ajax channels - requests from different channels can be
>> processed
>> in parallel, while requests within the same channel block.
>>
>> c) we have partial page updates of multiple components in a single
>> request -
>> do any of those frameworks have it? i briefly looked at ricko which
>> had a
>> similar ajax-envelope response that can encapsulate markup for multiple
>> parts of the page that need to be updated a while back - but it was
>> still
>> very immature.
> I wrote something like that in Wicket Dojo Contrib (DojoUpdateHandler)
>>
>> d) and the biggie - header contributions. we went through a lot of
>> pain to
>> ensure that if you have a <script> or a <link> to js markup in the
>> _ajax_
>> response - it will be properly executed by the browser. this is key for
>> component oriented frameworks. afaik neither dojo, nor scriptaculous,
>> nor
>> ricko, nor anyone else out there provide this functionality.
> I understand that but a framework like dojo does not need a such
> functionality because every script could be called by dojo.require()
> function
>>
>> if i missed something you guys feel free to pipe in.
>>
>> hope this explains it
>>
>> -igor
>>
>>
>>
>>
>> --
>>> Vincent Demay
>>> Systèmes d'Information
>>> ANYWARE TECHNOLOGIES
>>> Tel : +33 (0)561 000 649
>>> Fax : +33 (0)561 005 146
>>> http://www.anyware-tech.com/
>>>
>>>
>>
> PS : sorry to send previous mail twice (but sent it with a bad email
> adresse. Sorry)
>
Re: Why rewriting js librairies
Posted by Vincent demay <vi...@anyware-tech.com>.
Ok I understand that and I don't what to say that wicket dojo
implementation is bad because it's very cool ;)
Indeed using a framework as is could be difficult but using it to
develop required functionnalities could avoid to rewriting all from scratch.
Igor Vaynberg a écrit :
> On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>>
>> Hi,
>>
>> I ask myself a question. Why wicket needs to rewrite js libraries for
>> ajax or other client-side scripts or to include external scripts (date
>> picker for exemple).
>
>
> we are rewriting the datepicker because our old one was not compatible
> with
> ASL license - and using a huge thing like dojo is silly just for a
> datepicker.
>
> There are a lot of frameworks which work fine and
>> do everything needed in wicket such as Dojo, script.aculo.us, etc...Why
>> doesn't Wicket use one of them.
>
>
> because they dont do everything that wicket does :) our ajax impl is much
> more advanced then what dojo, scriptaculous and friends provides.
>
> a) the js lib needs to be ASL compatible since it would be packaged in
> our
> distro
I take dojo for example (because I know it more than the others)
I think dojo is compatible with ASL because it's used by Cocoon
>
> b) we have ajax channels - requests from different channels can be
> processed
> in parallel, while requests within the same channel block.
>
> c) we have partial page updates of multiple components in a single
> request -
> do any of those frameworks have it? i briefly looked at ricko which had a
> similar ajax-envelope response that can encapsulate markup for multiple
> parts of the page that need to be updated a while back - but it was still
> very immature.
I wrote something like that in Wicket Dojo Contrib (DojoUpdateHandler)
>
> d) and the biggie - header contributions. we went through a lot of
> pain to
> ensure that if you have a <script> or a <link> to js markup in the _ajax_
> response - it will be properly executed by the browser. this is key for
> component oriented frameworks. afaik neither dojo, nor scriptaculous, nor
> ricko, nor anyone else out there provide this functionality.
I understand that but a framework like dojo does not need a such
functionality because every script could be called by dojo.require()
function
>
> if i missed something you guys feel free to pipe in.
>
> hope this explains it
>
> -igor
>
>
>
>
> --
>> Vincent Demay
>> Systèmes d'Information
>> ANYWARE TECHNOLOGIES
>> Tel : +33 (0)561 000 649
>> Fax : +33 (0)561 005 146
>> http://www.anyware-tech.com/
>>
>>
>
PS : sorry to send previous mail twice (but sent it with a bad email
adresse. Sorry)
--
Vincent Demay
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)561 000 649
Fax : +33 (0)561 005 146
http://www.anyware-tech.com/
Re: Why rewriting js librairies
Posted by Igor Vaynberg <ig...@gmail.com>.
is someone writing a blog in wicket? :)
-igor
On 11/10/06, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > The whole wicket-ajax thing is bit more complicated, I'm up to blog
> > about it, but still waiting until we have "official" blog on
> > wicketframework.org :) (which can take couple of years it seems :))
>
> Do we have an issue for that? :)
>
> Ilko
>
Re: Why rewriting js librairies
Posted by Eelco Hillenius <ee...@gmail.com>.
> The whole wicket-ajax thing is bit more complicated, I'm up to blog
> about it, but still waiting until we have "official" blog on
> wicketframework.org :) (which can take couple of years it seems :))
Do we have an issue for that? :)
Ilko
Re: Why rewriting js librairies
Posted by Matej Knopp <ma...@knopp.sk>.
Yeah, that's pretty much it. I doubt there is anything that provides the
same functionality that wicket-ajax does.
starting with cross-browser outerHtml replacement functionality that
also evaluates inner scripts (that was the easier part :))
Updating multiple component on the same page, evaluating javascript and
doing header contribution in the same request. The header contribution
was the trickiest part. It is able to parse the header (<head></head>)
output of components and process it (load javascript references,
stylesheet references, add inline stylesheet, execute inline
javascript). And it does load the javascript files in the same order as
specified in <head> output, while doing that asynchronously - without
blocking the browser.
The whole wicket-ajax thing is bit more complicated, I'm up to blog
about it, but still waiting until we have "official" blog on
wicketframework.org :) (which can take couple of years it seems :))
-Matej
Igor Vaynberg wrote:
> On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>>
>> Hi,
>>
>> I ask myself a question. Why wicket needs to rewrite js libraries for
>> ajax or other client-side scripts or to include external scripts (date
>> picker for exemple).
>
>
> we are rewriting the datepicker because our old one was not compatible with
> ASL license - and using a huge thing like dojo is silly just for a
> datepicker.
>
> There are a lot of frameworks which work fine and
>> do everything needed in wicket such as Dojo, script.aculo.us, etc...Why
>> doesn't Wicket use one of them.
>
>
> because they dont do everything that wicket does :) our ajax impl is much
> more advanced then what dojo, scriptaculous and friends provides.
>
> a) the js lib needs to be ASL compatible since it would be packaged in our
> distro
>
> b) we have ajax channels - requests from different channels can be
> processed
> in parallel, while requests within the same channel block.
>
> c) we have partial page updates of multiple components in a single
> request -
> do any of those frameworks have it? i briefly looked at ricko which had a
> similar ajax-envelope response that can encapsulate markup for multiple
> parts of the page that need to be updated a while back - but it was still
> very immature.
>
> d) and the biggie - header contributions. we went through a lot of pain to
> ensure that if you have a <script> or a <link> to js markup in the _ajax_
> response - it will be properly executed by the browser. this is key for
> component oriented frameworks. afaik neither dojo, nor scriptaculous, nor
> ricko, nor anyone else out there provide this functionality.
>
> if i missed something you guys feel free to pipe in.
>
> hope this explains it
>
> -igor
>
>
>
>
> --
>> Vincent Demay
>> Systèmes d'Information
>> ANYWARE TECHNOLOGIES
>> Tel : +33 (0)561 000 649
>> Fax : +33 (0)561 005 146
>> http://www.anyware-tech.com/
>>
>>
>
Re: Why rewriting js librairies
Posted by Eelco Hillenius <ee...@gmail.com>.
> if i missed something you guys feel free to pipe in.
Well, just that in fact we started out using other libraries. From the
very start, Wicket's ajax support was setup independently from any
concrete javascript library. The first implementation was based on
DOJO after some unsuccessful experimentation with another library.
DOJO worked fine for us to start with, but like Igor outlined, we had
to bend our API and DOJO towards each other, which got to be a major
hassle.
So what we did, and what you see today, is we created a default,
Wicket supported, implementation that directly binds with the API we
have, and which is pretty minimal (only does what we need for Wicket).
But everyone can build their own implementations on it, which you can
for instance see in projects wicket-contrib-dojo and
wicket-contrib-scriptaculous (and potentially wicket-contrib-yui), all
of which reside in wicket-stuff.
Eelco
Re: Why rewriting js librairies
Posted by Igor Vaynberg <ig...@gmail.com>.
On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>
> Hi,
>
> I ask myself a question. Why wicket needs to rewrite js libraries for
> ajax or other client-side scripts or to include external scripts (date
> picker for exemple).
we are rewriting the datepicker because our old one was not compatible with
ASL license - and using a huge thing like dojo is silly just for a
datepicker.
There are a lot of frameworks which work fine and
> do everything needed in wicket such as Dojo, script.aculo.us, etc...Why
> doesn't Wicket use one of them.
because they dont do everything that wicket does :) our ajax impl is much
more advanced then what dojo, scriptaculous and friends provides.
a) the js lib needs to be ASL compatible since it would be packaged in our
distro
b) we have ajax channels - requests from different channels can be processed
in parallel, while requests within the same channel block.
c) we have partial page updates of multiple components in a single request -
do any of those frameworks have it? i briefly looked at ricko which had a
similar ajax-envelope response that can encapsulate markup for multiple
parts of the page that need to be updated a while back - but it was still
very immature.
d) and the biggie - header contributions. we went through a lot of pain to
ensure that if you have a <script> or a <link> to js markup in the _ajax_
response - it will be properly executed by the browser. this is key for
component oriented frameworks. afaik neither dojo, nor scriptaculous, nor
ricko, nor anyone else out there provide this functionality.
if i missed something you guys feel free to pipe in.
hope this explains it
-igor
--
> Vincent Demay
> Systèmes d'Information
> ANYWARE TECHNOLOGIES
> Tel : +33 (0)561 000 649
> Fax : +33 (0)561 005 146
> http://www.anyware-tech.com/
>
>
Re: Why rewriting js librairies
Posted by Ryan Sonnek <ry...@gmail.com>.
Just so you know,
There is a wicket-stuff project that integrates scriptaculous with Wicket.
There'll be quite a few additions to that project comming soon too!
On 11/10/06, Vincent demay <vi...@anyware-tech.com> wrote:
>
> Hi,
>
> I ask myself a question. Why wicket needs to rewrite js libraries for
> ajax or other client-side scripts or to include external scripts (date
> picker for exemple). There are a lot of frameworks which work fine and
> do everything needed in wicket such as Dojo, script.aculo.us, etc...Why
> doesn't Wicket use one of them.
>
> --
> Vincent Demay
> Systèmes d'Information
> ANYWARE TECHNOLOGIES
> Tel : +33 (0)561 000 649
> Fax : +33 (0)561 005 146
> http://www.anyware-tech.com/
>
>