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
On 11/10/06, Vincent demay [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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/
Re: Why rewriting js librairies
On 11/10/06, Vincent demay [EMAIL PROTECTED] 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 scriptalert('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
Igor Vaynberg a écrit :
On 11/10/06, Vincent demay [EMAIL PROTECTED] 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 scriptalert('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
On 11/10/06, Vincent demay [EMAIL PROTECTED] 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
