Re: wicketstuff-push: centralizing requests
Xavier Hanin wrote: Hi, I'm currently using wicketstuff-push to push events to a page and it works pretty well, but not well enough. Before trying to move to a comet based implementation, I would like to improve the timer based implementation. In the current implementation you got as many AjaxTimer as you install the push on components on the same page. So if you have three components requiring push, you will have three requests each x seconds, to poll for push events from the three components. This would be much more efficient if I had only one request polling for all push events sent by all components on the page... Hence my first thought was to add the timer behavior to the page instead of the component, and verify that the same kind of behavior is not already installed before installing a new one. The problem is that when I install the behavior the component doesn't know its page. So I have to do something at this time, and then later when I know the page make sure that only one behavior is actually rendered. I see two solutions to this problem: - Add one timer behavior to each component (as today), and then when rendering the component use the wasRendered/markRendered methods of IHeaderResponse to render only one of them (using the isEnabled method to disable it if another similar one has already been rendered). But then I will have to update all the non rendered behaviors so that push events sent to them are actually sent to the only behavior which is rendered. - Modify the API of the push service and ask to enable push on a page before actually using push on components on the page. This would actually install a unique timer behavior on the page. Then when installing push on a component I could simply add something which could be located by the unique timer on the page to collect all push events (maybe a disabled behavior) Now that I expose the two options I think I prefer the first one. But I would like to gather feedback from experienced wicket developers to see if I'm not missing something or if you have better ideas about how to implement what I want. Hy Xavier, I've got an idea but I don't know if it will be convenient: TimerPushBehavior should not extends AjaxTimerBehavior. TimerPushBehavior could now do : - Adding a javascript(jsMain) in the header (using a static id - render once). This javascript can manage ajax timer on a specific callback url. - Each TimerPushBehavior registers its component id on the previous added javascript(jsMain) - When a callback is received by the first added behavior: * get all id registered in jsMain (sent to the behavior as parameters of the callbackUrl) * look for each child(server side) by they component id (IVisitor) * look for TimerPushBehavior on each child * call onTimer method on each TimerPushBehavior of each Child it is may be a little bit hacked but it can be a solution. WDYT? -- Vincent Thanks, Xavier
IComponentInheritedModel IWrapModel just to get the component in model
Hi
I have a custom model where i need to access to the component. The only
method I found seems me a little bit overkill :
my model should implement IComponentInheritedModel and I also need to
declare a new class implementing IWrapModel to return on
wrapOnInheritance. Furthermore all this stuff is not really oriented to
simply get the component in the model. (maybe there is a better way?)
I thought about a very simple way :
Just creating a new interface :
IComponentAwareModel{ void setComponent(Component component)}
and adding in component.class
if (model instanceof IComponentAwareModel){
((IComponentAwareModel)model.setComponent(this))}
I think it also avoid to write 40 code lines just to get the component
in the model.
WDYT?
--
Vincent Demay
Wicket 1.3.0-beta2
Hi all, First of all, congrats for graduation and beta2 release. I've just checked out the new beta2 tags from svn and I was surprised to see 1.3.0-SNAPSHOT in all pom.xml instead of 1.3.0-beta2. So the big problem is in my maven repo because I can not have a beta2 and trunk release at same time. What do you think of changing all version number in pom.xml for beta2 tag (same form beta1)? Cheers -- Vincent Demay
Re: Wicket 1.3.0-beta2
Martijn Dashorst wrote: Use the releases/wicket-1.3.0-beta2 branch instead Oh right, thx ;) cheers -- Vincent Demay Martijn On 7/2/07, Vincent Demay [EMAIL PROTECTED] wrote: Hi all, First of all, congrats for graduation and beta2 release. I've just checked out the new beta2 tags from svn and I was surprised to see 1.3.0-SNAPSHOT in all pom.xml instead of 1.3.0-beta2. So the big problem is in my maven repo because I can not have a beta2 and trunk release at same time. What do you think of changing all version number in pom.xml for beta2 tag (same form beta1)? Cheers -- Vincent Demay
Re: remove test scope for slf4j in pom.xml
Oleg Taranenko a écrit : Hello Jean-Baptiste, Wednesday, June 13, 2007, 12:35:39 PM, you wrote: * Oleg Taranenko: Now I'm viewing wicket stuffs und some projects not started under mvn jetty:run reason of Please mention the WS projects at fault, we need to fix them. pickwick ;) Hi, I've just fixed it, have fun with pickwick ;) -- Vincent others are forgeted after my workaround had been founded...
Re: New WicketStuff developer: Grégory Maes
Jean-Baptiste Quenot a écrit : Dear developers, Please welcome Grégory Maes among the WicketStuff developers. Grégory has filed [1]several patches on WicketStuff Dojo, and has shown a long-term interest in this project. He now deserves to apply the changes himself. Welcome Grégory! Congratulation Grégory, Welcome ;) -- Vincent
Re: wicket-contrib-push: question about proxy = true
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in CometdEvent:
what
is it used for? Indeed I would like to get rid of CometdEvent, to make
implementation switch very easy, but I'm not sure if all cometd events
should always have this property set, or if only some should.
If I well remember I added this proxy value in CometdEvent to know if
an event has to be proxied by a behavior :
If you have a look at CometdDefaultBehaviorTemplate.js, I check if
proxy=true before making a callback to the bahavior (var
wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() { });).
The aim is to make a différence between an event/publisher/behavior
architecture and a simple one(as in sharedForm) if cometd events are
sent on the same channel.
If they all should have this data, I can do what I've already proposed
in my
patch (in a previous discussion on the user list). Otherwise the user
will
have to keep in control of this, and if it's suited to cometd
implementaiton
only, it will compromise my dream of transparent switching between
implementations :-)
If you think it is better to remove that in order to deal with all event
in the channel, feel free to do it, but we need make user aware of that
in javadoc. (a cometdEvent triggered by an event/publisher/behavior
architecture can be intercept by a simple one in there are in the same
channel).
An other solution is to add it in timer implementation, even if it is
useless, it's up to you ;)
hope my explaination is clear ;)
--
Vincent
TIA,
Xavier
Re: wicket-contrib-push: question about proxy = true
Xavier Hanin a écrit :
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in CometdEvent:
what
is it used for? Indeed I would like to get rid of CometdEvent, to make
implementation switch very easy, but I'm not sure if all cometd events
should always have this property set, or if only some should.
If I well remember I added this proxy value in CometdEvent to know if
an event has to be proxied by a behavior :
If you have a look at CometdDefaultBehaviorTemplate.js, I check if
proxy=true before making a callback to the bahavior (var
wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() {
});).
The aim is to make a différence between an event/publisher/behavior
architecture and a simple one(as in sharedForm) if cometd events are
sent on the same channel.
OK, now that I've investigated a little more the code I understand how
it is
used.
The problem is that this is not really what I expected, because you don't
fully take advantage of comet: indeed each time an event is published
on the
channel, it is sent to the server with only the parameters, then the
client
send a regular ajax request to the server to get the actual UI
modifications. This means that you will have one connection for comet,
plus
one connection for each comet event, which doesn't scale very well.
Yes exactly, With this way we can have different behaviors on differents
pages according to the data coming from the event. But it is
definitively not very scalable.
I thought we might be able to send directly the same content of the
envelop
sent by wicket on the ajax call directly in the comet event data (the
envelop processed by Wicket.Ajax.Call.loadedCallback). In this case we
would
be able to use the comet connection only, which would be much more
scalable
IMO. This is not really what cometd is meant for, and it means this API
wouldn't be usable to send regular cometd events. So maybe I'm talking
about
another implementation of a different concept, which could co exist
with the
one you provided.
I think it can be an other approach, sending directly in the event
xmlFragment, javascript etc.. . but this kind of data are not very
regular cometd events. CometD is supposed transport json, so data
embedded in a serialized javascript object. The question is can we
consider xmlFragment is a part of a json object value?
I see An other problem : Using this approach means we know in the
eventPublisher the page structure, so it is impossible to send event to
different pages. And the event is directly very linked to the HMI.
WDYT?
--
Vincent
WDYT?
If they all should have this data, I can do what I've already proposed
in my
patch (in a previous discussion on the user list). Otherwise the user
will
have to keep in control of this, and if it's suited to cometd
implementaiton
only, it will compromise my dream of transparent switching between
implementations :-)
If you think it is better to remove that in order to deal with all event
in the channel, feel free to do it, but we need make user aware of that
in javadoc. (a cometdEvent triggered by an event/publisher/behavior
architecture can be intercept by a simple one in there are in the same
channel).
Yes, this is because you post regular comet events, which I didn't
understand first. It also explain why the channel listener do not have
the
plain channel event, but only a map of strings. I think I'll need some
more
thoughts because I think we are trying to achieve to different things:
what
I need is server initiated refresh of the web page, using cometd
(could be
only comet actually I think) for the transport (or polling in degraded
mode). What we have for the moment is something which allows to easily
send
comet events, and on another hand easily react to these events on the
client
side to trigger a regular ajax call asking for page refresh. In your case
any one can send the simple comet event, with proxy set to true, it will
trigger the refresh with another call to the server. In my case only the
wicket app can send a comet event with the envelop attached: it's only a
transport mechanism, nothing else. That's why I think comet could be
enough,
no need for cometd. But I'm still not confortable enough with comet and
cometd to be sure of what I think.
So for the moment I will commit my changes as is, but I'd welcome
opinion to
see if my use case and proposed implementation make sense.
Xavier
An other solution is to add it in timer implementation, even if it is
useless, it's up to you ;)
hope my explaination is clear ;)
--
Vincent
TIA,
Xavier
Re: wicket-contrib-push: question about proxy = true
Xavier Hanin a écrit :
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Xavier Hanin a écrit :
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in
CometdEvent:
what
is it used for? Indeed I would like to get rid of CometdEvent, to
make
implementation switch very easy, but I'm not sure if all cometd
events
should always have this property set, or if only some should.
If I well remember I added this proxy value in CometdEvent to
know if
an event has to be proxied by a behavior :
If you have a look at CometdDefaultBehaviorTemplate.js, I check if
proxy=true before making a callback to the bahavior (var
wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() {
});).
The aim is to make a différence between an event/publisher/behavior
architecture and a simple one(as in sharedForm) if cometd events are
sent on the same channel.
OK, now that I've investigated a little more the code I understand how
it is
used.
The problem is that this is not really what I expected, because you
don't
fully take advantage of comet: indeed each time an event is published
on the
channel, it is sent to the server with only the parameters, then the
client
send a regular ajax request to the server to get the actual UI
modifications. This means that you will have one connection for comet,
plus
one connection for each comet event, which doesn't scale very well.
Yes exactly, With this way we can have different behaviors on differents
pages according to the data coming from the event. But it is
definitively not very scalable.
I thought we might be able to send directly the same content of the
envelop
sent by wicket on the ajax call directly in the comet event data (the
envelop processed by Wicket.Ajax.Call.loadedCallback). In this case we
would
be able to use the comet connection only, which would be much more
scalable
IMO. This is not really what cometd is meant for, and it means this
API
wouldn't be usable to send regular cometd events. So maybe I'm talking
about
another implementation of a different concept, which could co exist
with the
one you provided.
I think it can be an other approach, sending directly in the event
xmlFragment, javascript etc.. . but this kind of data are not very
regular cometd events. CometD is supposed transport json, so data
embedded in a serialized javascript object. The question is can we
consider xmlFragment is a part of a json object value?
I think this should be possible with proper escaping. Al of that is text
after all.
I see An other problem : Using this approach means we know in the
eventPublisher the page structure, so it is impossible to send event to
different pages. And the event is directly very linked to the HMI.
Indeed, but what is the added value of sending events to several pages if
all pages then have to ask the server what to actually do.
I think your implementation is very nice to actually use cometd for
what its
is meant for, and I think preserving the CometdPublisher for instance
is a
must. It makes cometd publishing really easy. The
AbstractCometdBehavior is
also very nice to easily add client side reaction to regular cometd
events.
But the idea of using this as is with a proxy mechanism can be misleading
IMO (well, I was surprised to see how it works :-)). So I think with
proper
documentation we can provide two services: channel service, where we
publish
events on channels which can be listened to the client, and push service
(maybe this time it's really only pushing), for server initiated page
refresh only, using cometd as a transport mechanism only (properly
documented as doing so).
Does it make sense?
Yes ;)
channel service will be Event-Client-Server-Client (Actual proxy)
pushing service will be Event-Client (needs to specify a 'protocole' or
a way to communicate via cometd json)
Did I well understand ?
--
Vincent
Xavier
WDYT?
--
Vincent
WDYT?
If they all should have this data, I can do what I've already
proposed
in my
patch (in a previous discussion on the user list). Otherwise the
user
will
have to keep in control of this, and if it's suited to cometd
implementaiton
only, it will compromise my dream of transparent switching between
implementations :-)
If you think it is better to remove that in order to deal with all
event
in the channel, feel free to do it, but we need make user aware of
that
in javadoc. (a cometdEvent triggered by an event/publisher/behavior
architecture can be intercept by a simple one in there are in the
same
channel).
Yes, this is because you post regular comet events, which I didn't
understand first. It also explain why the channel listener do not have
the
plain channel event, but only a map of strings. I think I'll need some
more
thoughts because I think we are trying to achieve to different things:
what
I need is server
Re: [Wicket-user] [announce] wicket 1.x development has moved to trunk in svn
OK, so I think it will be fine if we also switch - wicketstuff/trunk to wicketstuff/branches/wicket-2-DISCONTINUED - wicketstuff/branches/wicket1.x to wicketstuff/trunk -- Vincent Martijn Dashorst a écrit : We have now switched trunk and wicket 1.x in subversion. We have been getting reports of confused users about the status of Wicket and where to get the code from. We appologize for the inconvenience this will cause. From now on trunk is again our main development branch. The previous Wicket 2 *with* constructor change has now been moved to branches/wicket-2-DISCONTINUED and is in maintenance mode (i.e. only bug fixes on a case-by-case basis). * Switching Wicket 1.3 If you depended on branches/wicket-1.x do the following in your checked out working copy: svn switch http://svn.apache.org/repos/asf/incubator/wicket/trunk (if you are a Wicket committer, substitute http with https) * Switching Wicket 2 If you were working on trunk and want to stay with the latest in that branch you will need to do the following in your working copy: svn switch http://svn.apache.org/repos/asf/incubator/wicket/branches/wicket-2-DISCONTINUED (if you are a Wicket committer, substitute http with https) We will switch the svn branches in wicket-stuff too. Best regards, Martijn
Re: [Wicket-user] [announce] wicket 1.x development has moved to trunk in svn
Martijn Dashorst a écrit : On 4/19/07, Vincent Demay [EMAIL PROTECTED] wrote: If anyone else is willing to do it, fine by me, as long as we coordinate. As you want, you can do it, but if you are bored with svn mv, I can do it I don't mind doing it. Ok, do it ;) I propose we do the switch for wicketstuff at (or around) 6pm CET (for us euros: 18:00 central european time). Why 18:00? is it your favorite time in the day ;) ? It is because then the west coast of the US is awake for a couple of hours, so they also have the opportunity to perform their last commits. And for us euro boys a whole working day. Martijn
Re: [wicketstuff dojo] The wicketstuff namespace
Bart Molenkamp a écrit :
Hi,
I committed my changes. Take a look at the package
org.wicketstuff.dojo.dojodnd. For example, look how DojoDragContainer
is declared, and how DojoDragCopyContainer extends it (it overrides
the createDragSource() function to create a different kind of drag
source). The *Template.js files are not used anymore, they could be
deleted.
I also added a new sample, see the package
org.wicketstuff.dojo.examples.dnd (JS classes extending the base drag
and drop classes). I updated the existing dnd samples to demonstrate
the DojoDragCopyContainer as well.
Bart.
Hi bart,
I'm looking at it. I like the concept, and it is particulary usefull for
dnd. But I've got a problem, wicketstuff seems to be unreachable in
exemples :
[Exception... 'Error: ReferenceError: wicketstuff is not defined' when
calling method: [nsIDOMEventListener::handleEvent] nsresult:
0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT) location: unknown
data: no]
Could not load 'wicketstuff.dojodnd.DojoDragCopyContainer'; last tried
'__package__.js'
I checked genarated js, and it seems OK :
script type=text/javascript
src=resources/org.wicketstuff.dojo.AbstractDefaultDojoBehavior/dojo-0.4/dojo.js/script
script type=text/javascript
src=resources/org.wicketstuff.dojo.AbstractRequireDojoBehavior/dojo-wicket/dojoWicket.js/script
script type=text/javascript
id=org.wicketstuff.dojo.AbstractDefaultDojoBehavior/namespaces/wicketstuff!--/*--![CDATA[/*!--*/
dojo.registerModulePath(wicketstuff,
../../../resources/org.wicketstuff.dojo.AbstractDefaultDojoBehavior/)/*--]]*//script
[...]
script type=text/javascript
id=org.wicketstuff.dojo.AbstractRequireDojoBehavior!--/*--![CDATA[/*!--*/
dojo.require(dojo.io.*)
dojo.require(dojo.dnd.*)
dojo.require(dojo.event.*)
dojo.require(wicketstuff.dojodnd.DojoDropContainer)
/*--]]*//script
script type=text/javascript
id=dropContainer0onLoad!--/*--![CDATA[/*!--*/
dojo.event.connect(dojo, loaded, function() {new
wicketstuff.dojodnd.DojoDropContainer('dropContainer0', ['*'],
'?wicket:interface=:14:dropContainer:-1:IUnversionedBehaviorListener:0wicket:ignoreIfNotActive=true').initializeDropContainer();
});
/*--]]*//script
[...]
any idea?
--
Vincent
Re: [Wicket-autocvs] SF.net SVN: wicket-stuff: [1935] branches/wicket-1.3/wicket-contrib-dojo/ src/main/java/org/wicketstuff/dojo
Hi Bart
I see you added a behavior to deal with Dojo widget creating it using
dojo.widget.createWidget. I don't understand what is the aim of this
abstract behavior because AbstractRequireDojoBehavior can already create
a dojo widget via an AjaxRequestTarget (see TargetRefresherManager which
is a listener on ajaxRequest Target) but I maybe miss something.
The way we choose to create dojo widget in Wicket is adding parameters
on the component tag. AbstractDojoWidgetBehavior deals with
dojo.widget.createWidget and extending AbstractRequireDojoBehavior the
widget created with this behavior could be added twice in the dojoManager.
On the other hand it will be great to keep a unique way to create widget
in WCD. I'm not saying the way we use now is the better but it can be
better if we use always the same (adding attribute on component tag OR
using dojo.widget.createWidget).
Just say me if I simply not well understand the goal of this class ;) .
Otherwise we need to choose a *unique* way to render dojo widget and
apply it on all widgets.
--
Vincent
[EMAIL PROTECTED] a écrit :
Revision: 1935
http://svn.sourceforge.net/wicket-stuff/?rev=1935view=rev
Author: molenkampb
Date: 2007-04-16 23:56:42 -0700 (Mon, 16 Apr 2007)
Log Message:
---
* Introduced AbstractDojoWidgetBehavior that can create widgets when first
rendered and after rerendering (by ajax)
branches/wicket-1.3/wicket-contrib-dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java
===
---
branches/wicket-1.3/wicket-contrib-dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java
(rev 0)
+++
branches/wicket-1.3/wicket-contrib-dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java
2007-04-17 06:56:42 UTC (rev 1935)
@@ -0,0 +1,169 @@
+/**
+ *
+ */
+package org.wicketstuff.dojo;
+
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.Map;
+
+import org.apache.wicket.IRequestTarget;
+import org.apache.wicket.RequestCycle;
+import org.apache.wicket.ResourceReference;
+import org.apache.wicket.ajax.AjaxRequestTarget;
+import org.apache.wicket.markup.html.IHeaderResponse;
+
+/**
+ * Abstract behavior implementation that deals with dojo widgets.
+ *
+ * @author B. Molenkamp
+ * @version SVN: $Id$
+ */
+public abstract class AbstractDojoWidgetBehavior extends
AbstractRequireDojoBehavior {
+
+ /* (non-Javadoc)
+* @see
org.wicketstuff.dojo.AbstractRequireDojoBehavior#renderHead(org.apache.wicket.markup.html.IHeaderResponse)
+*/
+ @Override
+ public void renderHead(IHeaderResponse response) {
+ super.renderHead(response);
+
+ String markupId = getComponent().getMarkupId();
+ WidgetProperties props = getWidgetProperties();
+ String arrayString = props.convertToJavaScriptArray();
+
+ IRequestTarget target = RequestCycle.get().getRequestTarget();
+ if(!(target instanceof AjaxRequestTarget)){
+ response.renderJavascript(dojo.event.connect(dojo,
\loaded\, function() { +
+ dojo.widget.createWidget(' + getWidgetType() + ', +
arrayString + , dojo.byId(' + markupId + ')) +
+ });\n,
+ markupId + onLoad);
+ }
+ }
+
+ /* (non-Javadoc)
+* @see
org.wicketstuff.dojo.AbstractRequireDojoBehavior#onComponentReRendered(org.apache.wicket.ajax.AjaxRequestTarget)
+*/
+ @Override
+ public void onComponentReRendered(AjaxRequestTarget ajaxTarget) {
+ super.onComponentReRendered(ajaxTarget);
+
+ String markupId = getComponent().getMarkupId();
+
+
+ //dojo.widget.createWidget(Editor2, {},
dojo.byId(editorContent));
+ WidgetProperties props = getWidgetProperties();
+ String arrayString = props.convertToJavaScriptArray();
+ ajaxTarget.appendJavascript(dojo.widget.createWidget(' + getWidgetType() + ',
+ arrayString + , dojo.byId(' + markupId + '));\n);
+ }
+
+ /**
+* Returns the widget type.
+* @return
+*/
+ protected abstract String getWidgetType();
+
+ /**
+* Return the properties string that is used when creating the widget.
+* @return
+*/
+ protected WidgetProperties getWidgetProperties() {
+ // by default return an empty map.
+ return new WidgetProperties();
+ }
+
+ /**
+* A class to hold widget properties.
+*/
+ public class WidgetProperties {
+
+ private MapString, String properties;
+
+ public WidgetProperties() {
+ this.properties = new HashMapString,
Re: [Wicket-autocvs] SF.net SVN: wicket-stuff: [1935] branches/wicket-1.3/wicket-contrib-dojo/ src/main/java/org/wicketstuff/dojo
Bart Molenkamp a écrit :
Hi Vincent,
I wasn't aware of the TargetRefreshManager class. I found out that the
DojoRichTextBehavior didn't work when the component was added to the page after
an Ajax update (in my case I replaced some panel with another panel that
contained the rich text editor). The solution would be call to
dojo.hostenv.makeWidgets(); (I see this is done by the TargetRefreshManager).
More than creating widget, TargetRefresherManager ensure also that the
widget will be created before all appendJavascript interpretation which
is quite usefull when we want add some javascript dealing with the
widget created by an ajax response
But I choose to create the widgets by hand, because then I can add parameters to it. If you look at the DojoRichTextBehavior you can see that it's possible to set some properties, like height, and the toolbar template. These properties are passed to the createWidget call in JavaScript. Is it possible to add these parameters to a widget if you use the dojoType=Editor2 tag to create widgets?
Probably yes, Dojo actually parse all attributes in a dojoType tags to
use each one as a setter of the class attribute (if exists) during
widget creation. So It should work expect if there is a bug in dojo ;)
I think you're right that it might become a problem when the same widget is
created more than once. I didn't thought about it.
We should indeed use one (and only one) way to create/maintain widgets.
TargetRefreshManager is OK by me (thinking of it, I guess that it failed to
create the widget due to the bug in RichText.js) if I can pass parameters on
creation (I need the height and the custom toolbar for the Editor2 widget).
Thanks for looking at this,
no pb !
Bart.
--
Vincent
-Oorspronkelijk bericht-
Van: Vincent Demay [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 17 april 2007 10:28
Aan: wicket-dev@incubator.apache.org
Onderwerp: Re: [Wicket-autocvs] SF.net SVN: wicket-stuff: [1935]
branches/wicket-1.3/wicket-
contrib-dojo/ src/main/java/org/wicketstuff/dojo
Hi Bart
I see you added a behavior to deal with Dojo widget creating it using
dojo.widget.createWidget. I don't understand what is the aim of this
abstract behavior because AbstractRequireDojoBehavior can already create
a dojo widget via an AjaxRequestTarget (see TargetRefresherManager which
is a listener on ajaxRequest Target) but I maybe miss something.
The way we choose to create dojo widget in Wicket is adding parameters
on the component tag. AbstractDojoWidgetBehavior deals with
dojo.widget.createWidget and extending AbstractRequireDojoBehavior the
widget created with this behavior could be added twice in the dojoManager.
On the other hand it will be great to keep a unique way to create widget
in WCD. I'm not saying the way we use now is the better but it can be
better if we use always the same (adding attribute on component tag OR
using dojo.widget.createWidget).
Just say me if I simply not well understand the goal of this class ;) .
Otherwise we need to choose a *unique* way to render dojo widget and
apply it on all widgets.
--
Vincent
[EMAIL PROTECTED] a écrit :
Revision: 1935
http://svn.sourceforge.net/wicket-stuff/?rev=1935view=rev
Author: molenkampb
Date: 2007-04-16 23:56:42 -0700 (Mon, 16 Apr 2007)
Log Message:
---
* Introduced AbstractDojoWidgetBehavior that can create widgets when first
rendered and after
rerendering (by ajax)
branches/wicket-1.3/wicket-contrib-
dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java
===
--- branches/wicket-1.3/wicket-contrib-
dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java
(rev 0)
+++ branches/wicket-1.3/wicket-contrib-
dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java
2007-04-17 06:56:42
UTC (rev 1935)
@@ -0,0 +1,169 @@
+/**
+ *
+ */
+package org.wicketstuff.dojo;
+
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.Map;
+
+import org.apache.wicket.IRequestTarget;
+import org.apache.wicket.RequestCycle;
+import org.apache.wicket.ResourceReference;
+import org.apache.wicket.ajax.AjaxRequestTarget;
+import org.apache.wicket.markup.html.IHeaderResponse;
+
+/**
+ * Abstract behavior implementation that deals with dojo widgets.
+ *
+ * @author B. Molenkamp
+ * @version SVN: $Id$
+ */
+public abstract class AbstractDojoWidgetBehavior extends
AbstractRequireDojoBehavior {
+
+ /* (non-Javadoc)
+* @see
org.wicketstuff.dojo.AbstractRequireDojoBehavior#renderHead(org.apache.wicket.markup.html.IHeaderRe
sponse)
+*/
+ @Override
+ public void renderHead(IHeaderResponse response) {
+ super.renderHead(response);
+
+ String markupId = getComponent().getMarkupId();
+ WidgetProperties props = getWidgetProperties
Re: [Wicket-autocvs] SF.net SVN: wicket-stuff: [1935] branches/wicket-1.3/wicket-contrib-dojo/ src/main/java/org/wicketstuff/dojo
Bart Molenkamp a écrit : Done. Vincent, could you please check if this is the way to go? Hope everything is ok for you (about refresh). It seems ok for me thx. -- Vincent Thanks, Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: dinsdag 17 april 2007 12:15 Aan: wicket-dev@incubator.apache.org Onderwerp: RE: [Wicket-autocvs] SF.net SVN: wicket-stuff: [1935] branches/wicket-1.3/wicket- contrib-dojo/ src/main/java/org/wicketstuff/dojo Ok, I can just simply add my configuration parameters using ComponentTag.put(). Also reloading works (probably didn't work in the first case due to the bug in RichText.js). I will remove the AbstractDojoWidgetBehavior class. Thanks, Bart. -Oorspronkelijk bericht- Van: Vincent Demay [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 17 april 2007 11:35 Aan: wicket-dev@incubator.apache.org Onderwerp: Re: [Wicket-autocvs] SF.net SVN: wicket-stuff: [1935] branches/wicket-1.3/wicket- contrib-dojo/ src/main/java/org/wicketstuff/dojo Bart Molenkamp a écrit : Hi Vincent, I wasn't aware of the TargetRefreshManager class. I found out that the DojoRichTextBehavior didn't work when the component was added to the page after an Ajax update (in my case I replaced some panel with another panel that contained the rich text editor). The solution would be call to dojo.hostenv.makeWidgets(); (I see this is done by the TargetRefreshManager). More than creating widget, TargetRefresherManager ensure also that the widget will be created before all appendJavascript interpretation which is quite usefull when we want add some javascript dealing with the widget created by an ajax response But I choose to create the widgets by hand, because then I can add parameters to it. If you look at the DojoRichTextBehavior you can see that it's possible to set some properties, like height, and the toolbar template. These properties are passed to the createWidget call in JavaScript. Is it possible to add these parameters to a widget if you use the dojoType=Editor2 tag to create widgets? Probably yes, Dojo actually parse all attributes in a dojoType tags to use each one as a setter of the class attribute (if exists) during widget creation. So It should work expect if there is a bug in dojo ;) I think you're right that it might become a problem when the same widget is created more than once. I didn't thought about it. We should indeed use one (and only one) way to create/maintain widgets. TargetRefreshManager is OK by me (thinking of it, I guess that it failed to create the widget due to the bug in RichText.js) if I can pass parameters on creation (I need the height and the custom toolbar for the Editor2 widget). Thanks for looking at this, no pb ! Bart. -- Vincent -Oorspronkelijk bericht- Van: Vincent Demay [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 17 april 2007 10:28 Aan: wicket-dev@incubator.apache.org Onderwerp: Re: [Wicket-autocvs] SF.net SVN: wicket-stuff: [1935] branches/wicket-1.3/wicket- contrib-dojo/ src/main/java/org/wicketstuff/dojo Hi Bart I see you added a behavior to deal with Dojo widget creating it using dojo.widget.createWidget. I don't understand what is the aim of this abstract behavior because AbstractRequireDojoBehavior can already create a dojo widget via an AjaxRequestTarget (see TargetRefresherManager which is a listener on ajaxRequest Target) but I maybe miss something. The way we choose to create dojo widget in Wicket is adding parameters on the component tag. AbstractDojoWidgetBehavior deals with dojo.widget.createWidget and extending AbstractRequireDojoBehavior the widget created with this behavior could be added twice in the dojoManager. On the other hand it will be great to keep a unique way to create widget in WCD. I'm not saying the way we use now is the better but it can be better if we use always the same (adding attribute on component tag OR using dojo.widget.createWidget). Just say me if I simply not well understand the goal of this class ;) . Otherwise we need to choose a *unique* way to render dojo widget and apply it on all widgets. -- Vincent [EMAIL PROTECTED] a écrit : Revision: 1935 http://svn.sourceforge.net/wicket-stuff/?rev=1935view=rev Author: molenkampb Date: 2007-04-16 23:56:42 -0700 (Mon, 16 Apr 2007) Log Message: --- * Introduced AbstractDojoWidgetBehavior that can create widgets when first rendered and after rerendering (by ajax) branches/wicket-1.3/wicket-contrib- dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java === --- branches/wicket-1.3/wicket-contrib- dojo/src/main/java/org/wicketstuff/dojo/AbstractDojoWidgetBehavior.java (rev 0
Re: [wicketstuff dojo] JS inheritance and the wicketstuff namespace
Bart Molenkamp a écrit : Vincent Demay wrote: If I well understand it is a class named wicketstuff giving access to each function of each package as a subclass of wicketstuff? I like that, so +1 I don't understand exactly what you mean. I now have classes coded in JavaScript (similair like most - if not all - classes are coded in dojo) and I configured dojo to know where to find classes in the wicketstuff namespace. There isn't anything like a wicketstuff class. I need to do some cleanup, then I'll checkin. You'll see what I mean, and it can be easily reverted if we deceide that we don't like it, OK? fine, no pb Bart.
Re: [wicketstuff dojo] JS inheritance and the wicketstuff namespace
If I well understand it is a class named wicketstuff giving access to each function of each package as a subclass of wicketstuff? I like that, so +1 -- Vincent Jean-Baptiste Quenot a écrit : * Bart Molenkamp: I wanted to make better use of JavaScript inheritance using Dojo. snip/ Therefore, I created a dojo module named wicketstuff, which can access anything under org.wicketstuff.dojo. For example, I now have a javascript class wicketstuff.dojodnd.DojoDropContainer (org/wicketstuff/dojo/dojodnd/DojoDropContainer.js). I can extend this class in JavaScript and override the onDrop function to handle my specific requirements (remove all html children after the drop). Same for the drop indicator. snip/ Is this something that is useful? It's a small change, that currently only affects DojoDragContainer and DojoDropContainer (and it shouldn't break dnd as far as I can see), so shall I check it in so that others can look at it? If it works as easily as you describe, that's a great new feature, so +1 go on with your changes, and an example would be nice.
Re: Animation libs compared: animate.js versus Yahoo! Animation
Martijn Dashorst a écrit : All, I've been working for a while now on an animated homepage for wicket (not that we *have* to use it, it is a gimmick), and it was originally based on animate.js (the proposed animation library). I also converted it to yahoo animation (which is quite similar), and this way we can see the differences between the two (peformance, API, etc). You can see the difference between the two libs here: http://people.apache.org/~dashorst/animation/animator.html http://people.apache.org/~dashorst/animation/yahoo.html If you want to see the difference between rendering engines: I found that firefox has the best javascript support for these animations. Safari runs at a snails pace (I had to tweak the animation for that to make it run faster). Lessons learned: - animate.js is a really nice and powerful library - yahoo animation gives similar results, and has a bit better animation management - safari sucks performance wise for javascript - the api for yahoo and animate is strikingly similar, with just a couple of differences I haven't tested this with IE so that may be completely broken. Martijn Waoh, nice work ;) On OSX + firefox 2, animator seems to work better than yahoo : - animator is smoother than yahoo for the animations, fade gives same results with both librairies On OSX + Safari - animations are very slow with both librairies but animator *seems* to work nicer. fade works fine On Windows + IE6 - On both, texts supposed to appear in fade are visible at page loading and go to the right position at the end with fading - with IE, logo Animation is also smoother with animator On Ubuntu + Firefox2 - animator works fine, yahoo sucks with logo animation -- Vincent
Re: [proposal] adopt animate.js into wicket-extensions as our core effects library
Martijn Dashorst a écrit :
All,
I have found a nice animation library that is not as big as
scriptaculous, in my opinion better than moo and that fits pretty good
into the wicket philosophy. I'm talking about animate.js [1].
It is not the most widely adopted javascript library, but it packs a
helluva functionality in about 24kb.
The library works very simple and elegantly. It provides the
possibility to animate between css classes, which I find one of the
best features: styling information like colors, opacity defined in
your css instead of the javacode.
For example, the following style based animation:
ex15 = new Animator().addSubject(new CSSStyleSubject(
document.getElementById('ex15Button'),
width: 10em; background-color: rgb(256, 256, 256); font-style:
normal,
width: 40em; background-color: #F39; font-style: italic));
// note how you can use any unit, not just 'px'.
Becomes using classes:
ex16 = new Animator().addSubject(new CSSStyleSubject(
$('ex16Button'), small white, big blue bendy));
// the classes small, big, white, blue and bendy are defined in this
page's source.
(Taken from [1]).
It is safari compatible (the examples work for me), which means it
even works in a more obscure browser. The animations are stable (don't
break with multiple clicks).
The animate.js should work out of the box without conflicts with dojo
and prototype. It doesn't redefine core classes, making it orthogonal.
The library is BSD licensed, and seems pretty much 'done'. The 24kb
will be even smaller after our compression.
What do you think?
Even for a pro Dojo man as me ;) , I find this library very interesting
and easy to use.
If you choose to integrate this library in Wicket (I hope), I'll be
happy to help you if you need some help.
Cheers
--
Vincent
Martijn
[1] http://berniecode.com/writing/animator.html
Re: [proposal] adopt animate.js into wicket-extensions as our core effects library
Al Maw a écrit :
Martijn Dashorst wrote:
On 4/13/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I'm mainly thinking nice but do you have any concrete plans
(components, behavior) for it?
I think just a behavior (or class) with some examples. The philosophy
of the library is to not create 200 classes for every effect known to
man, which is what moo, rico, dojo and scriptaculous do. This library
is an enabling library for effects.
What about a simple Behavior, I think behavior is easier to use for the
end user
class onRefreshAnimationBehavior extends AbstractBehavior{
onRendered(){
if(AjaxRequestTarget){
target.prependJavascript(getFromEffect())
target.appendJavascript(getToEffect());
}
}
CharSequence getFromEffect();
CharSequance getToEffect();
}
so user can extend it, ie
onRefreshAnimatedClassBehavior(fromClass, toClass)
in order to do
component.add(new onRefreshAnimatedClassBehavior(yellow, default));
--
Vincent
We could use it to provide an AccordionPanel without constraining you
to prototype or moo or whatever.
We could easily provide framework support for fade-from-yellow
highlights (the standard draw-attention-to-updated-items AJAX idiom).
A simple Java API to invoke transitions with AjaxRequestTarget would
be really cool (we could provide some predefined ones, I guess).
target.appendAnimation(component, new Highlight());
target.appendAnimation(component, new Highlight().setColour(#ff));
target.appendAnimation(component, new FromClass(yellow));
target.prependAnimation(component,
new Animation[] {
new ToClass(wider), new ToClass(taller)
}
);
That sort of thing. :-)
Al
Re: Dojo build is now triggered when extensions is build
Frank Bille a écrit : On 4/13/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: * Frank Bille: FYI, I have just made Dojo 1.3 being build in bamboo when wicket-extensions 1.3 is build. Just curious, why? I saw that dojo depended on wicket/extensions 1.3 snapshot and thought hey, wouldn't bamboo be a cool way to ensure that dojo is in sync with wicket?. Is it the same with wicket (core)? -- Vincent Frank
Re: Dojo build is now triggered when extensions is build
Vincent Demay a écrit : Frank Bille a écrit : On 4/13/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: * Frank Bille: FYI, I have just made Dojo 1.3 being build in bamboo when wicket-extensions 1.3 is build. Just curious, why? I saw that dojo depended on wicket/extensions 1.3 snapshot and thought hey, wouldn't bamboo be a cool way to ensure that dojo is in sync with wicket?. Is it the same with wicket (core)? wicket/extensions 1.3 seems to be yes ;). I will read twice next time before relying :p ! -- Vincent Frank
Re: [proposal] adopt animate.js into wicket-extensions as our core effects library
Martijn Dashorst a écrit :
On 4/13/07, Vincent Demay [EMAIL PROTECTED] wrote:
What about a simple Behavior, I think behavior is easier to use for the
end user
class onRefreshAnimationBehavior extends AbstractBehavior{
onRendered(){
if(AjaxRequestTarget){
target.prependJavascript(getFromEffect())
target.appendJavascript(getToEffect());
}
}
CharSequence getFromEffect();
CharSequance getToEffect();
}
so user can extend it, ie
onRefreshAnimatedClassBehavior(fromClass, toClass)
in order to do
component.add(new onRefreshAnimatedClassBehavior(yellow, default));
This is creating a complete slew of new behaviors. I don't like that.
We have to implement it in a way, that we don't increase the API too
much.
I'm not sure it need to create a huge set of behavior, just one (or 2)
with a default implementation for getFromEffect and getToEffect
If user want to create its own one he should extend it and write its own
implementation.
I think behavior is the less intrusive way to integrate some refresh
decorator, moreover behavior encapsulate all stuffs concerning effect
in a simple class and do not need to a new Api to generate effects which
should be used to append JS on a ajaxRequestTarget - (if api exists it
is an inner one).
What Al coined seems like a nice option (needs a bit polish imo, but
the basic idea seems sound), *if* we want to support animation as a
core functionality. This would increase the API for the
AjaxRequestTarget. Couldn't we implement it in a less intrusive way,
so that the scriptaculous/dojo/moo fans can plug into our animation
aware target?
Martijn
Re: Package rename at SourceForge
Ryan Sonnek a écrit : I like that idea and think it would make sense for the other wicket-contrib-* projects to do the same. along with the package renaming, i think it's important for the project artifact to be updated as well. groupID = org.wicketstuff artifactID = dojo ??? +1 Hope every wicketstuff project will move to org.wicketstuff for packages and maven artifact. I like this idea. Thanks jbq to rename the project -- Vincent On 4/10/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: I'm thinking of renaming to org.wicketstuff.dojo instead. WDYT? -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: [wicket-contrib-dojo] JDK 1.4 or JDK 1.5?
Hi Bart Actually WCD was jdk1.4 compliant but a recent issue has been open (http://81.17.46.170:8090/jira/browse/DOJO-27) to move to 1.4. But you are right. We also need to move example from 1.4 to 1.5. I will update pom.xml file. Cheers -- Vincent Bart Molenkamp a écrit : Hi, I'm a little bit confused about wicket-contrib-dojo and their minimum JDK requirement (1.4 or 1.5). Currently, it seems that wicket-contrib-dojo requires 1.5 and that wicket-contrib-dojo-examples requires 1.4. This last one isn't building because it contains @Override annotations in the sample code, which doesn't work with JDK 1.4. So, should it use 1.4 (and thus remove the annotations) or use 1.5 (update pom.xml)?? Thanks, Bart.
Re: Going from setVisible(false) to setVisible(true) does not work without surounding element
After all this discuss, I made again a patch using Igor method : setoutputmarkuptag see https://issues.apache.org/jira/secure/attachment/12353976/Component.java.365.patch.txt WDYT? I hope it will be ok for all ;) -- Vincent Eelco Hillenius a écrit : What? Why should the inner component render when parent is not visible? This just doesn't make sense. +1 Eelco
Re: Going from setVisible(false) to setVisible(true) does not work without surounding element
Igor Vaynberg a écrit :
you have to get out of your ajax tunnel vision.
take the datepicker example. it needs the outputmarkupid(true) so that it
can tie the datepicker js to the textfield. but when the datepicker is
not
visible why should an empty tag still be there?
ok, so +1 for your code snippet.
If i want to discuss again about that it was to find the better way to
go from invisible to visible in ajax. Sorry for my ajax tunnel vision
;) but I think every vision are important in a chat, I think we have
now something that everybody feels acceptable.
Thanks
--
Vincent
-igor
On 3/19/07, Vincent Demay [EMAIL PROTECTED] wrote:
Igor Vaynberg a écrit :
no its not.
what i am trying to say is that setoutputmarkupid should be
independent from
this behavior. you are really making the meaning of
setoutputmarkupid(true)
ambiguous. all it is saying is that when the tag is rendered i want it
to
include the id attribute, you are changing that meaning to also
include the
output tag and not leaving me with any option to go back to the
original
behavior - which is very bad.
I think if you ask to display the markupid (setoutputmarkupid(true)) and
setVisible(false) on your component, you will never find in your dom the
id you asked to display, I think it is also disturbing
Imho i d'ont think it change the meaning of setoutputmarkupid.
--
Vincent
-igor
On 3/19/07, Vincent Demay [EMAIL PROTECTED] wrote:
Igor Vaynberg a écrit :
what you need is a different method. instead of
setoutputmarkupid(true) you
need something that will do
setoutputmarkuptag(boolean b) {
if (b) {
setoutputmarkupid(true);
setflag(outputmarkuptag,true);
} else {
setflag(outputmarkuptag,false);
//not sure if we should undo setoutputmarkupid here
}
}
Yes, it is the current behavior of the patch ;) actually, the current
behavior is
if outputMarkupid == true
render componentTag + attribute style and id
else
render nothing
so if you want to render nothing just set outputMarkupId to false,
for
the behavior we proposed just setoutputMarkupId to true
It is exactly what you describe in setoutputmarkuptag ;)
--
Vincent
now this will solve the problems outlined so far
btw the latest patch attached to the issue is bad because it
executes
behaviors which should not happen.
what i am worried about are javascript libraries and css. does
css 3
have
support for odd/even selectors? that will break. this will even
break
css 2
first child selector if that happens to be invisible because i dont
think it
checks for the display attribute. it will also break 3rd party
javascript
libs that dont check for display attrs.
i see how this makes life easier, but it also has a potential to be
evil.
that is why i closed the issue as wont-fix and told vincent to
bring the
discussion here on the list before we go any further.
-igor
On 3/19/07, Matej Knopp [EMAIL PROTECTED] wrote:
I don't like it. I don't think deprecating set/isVisible is the
way to
go. Plus there are other reasons: As now we use one flag for
visible
status. With your approach you'd require an enum, int, byte or
something similiar, that takes more space then just one bit in
flags.
I think we can just make a getter, that by default returns the
value
from application settings. And you can override that for your
component, if you want something different that what's set in
application settings.
-Matej
On 3/19/07, Vincent Demay [EMAIL PROTECTED] wrote:
Frédéric Bertin a écrit :
Martijn Dashorst wrote:
it seems taht this kind of construction is used to make
workaround
of
the bug. Is'n it?
First, what bug? I don't know that this is a bug? I thought
we are
discussing a feature here. Secondly, this is not a
workaround, but
creating client side code based on a API contract:
setVisible(false)
removes the component markup completely, including its tags,
from the
final markup.
ok, then there's a need for 2 different mechanisms.
One to switch a component visibility. This one should be
*reversible*
(in ajax or not), and then it should always output a tag with
an id
attribute (actually, can be done only when
setOutputMarkupId is
set to
true).
Another to render or not a component in the output markup.
This one
should be documented as *not reversible*. This is the current
setVisible implementation.
wdyt?
+1
What about keeping current behavior on setVisible
(deprecated) and
add a method setVisibility :
- none : render nothing
- visible : render all
- invisible : render only container tag with
style:display-none
Add in documentation
none: can not become visible in ajax
in visible: can
I think it will match to all use case, no ?
It is based on the assumption
Re: Going from setVisible(false) to setVisible(true) does not work without surounding element
Martijn Dashorst a écrit :
I know that, but that is not what a user expects... This patch wants
to make ajax visibilitiy changes easier and more transparent. But this
case doesn't work.
Think from a framework perspective instead of just pushing the patch.
What can break, what doesn't work, what else have we forgotten? Play
advocate of the devil.
Now if we don't render child component tags, then the check
document.getElementById('foo').style.display == 'none' fails. So we
now introduce ternairy logic. An element can be hidden or not present
at all. But before this patch it was just not available.
Yes but i think ternairy logic is explicitally introduced by user
(calling setOutputMarkupTag(true)). In other case, the logic is the same
as before
so user know that and can adapt his js.
How does this functionality work with security? Does
setOutputMarkupTag work regardless of authorization? If I'm not
authorized, does the tag render? Or not?
Even if the tag is rendered, it will be empty. Will it cause a security
problem? : it is a tag without any data in it
Martijn
On 3/20/07, Vincent Demay [EMAIL PROTECTED] wrote:
Martijn Dashorst a écrit :
No, because when you set output markuptag on the link *AND* on the
label, what should it do? Those are in conflict. And don't work as
advertised. This is completely going against what we designed
visibility to do: not render markup.
If you put setVisible(false) setOutputMarkupTag(true) on both
component, only the parent one will be render :
foo = new Link(foo);
foo.setVisible(false);
foo.setOutputMarkupTag(true)
bar = new label(bar);
bar.setVisible(false);
bar.setOutputMarkupTag(true)
add(foo);
foo.add(bar);
you will have :
a id=foo0/a
have a look in patch : markupStream.skipComponent(); will skip child
components
--
Vincent
When I do this:
new Link(foo)
.add(new Label(bar, foobar))
.setOutputWhatever(true)
.setVisible(false);
I expect this:
a href=# wicket:id=foo id=foo style=display:none/a
And NOT:
a href=# wicket:id=foo id=foo style=display:none
span wicket:id=bar style=display:none/span
/a
Martijn
On 3/20/07, Vincent Demay [EMAIL PROTECTED] wrote:
Martijn Dashorst a écrit :
One of my major pain points here is not discussed yet. And that is
nested invisible components.
a href=# wicket:id=foospan wicket:id=bar/span/a
new Link(foo).add(new Label(bar)).setVisible(false)
...
onAjaxThing(target) {
bar.setVisible(true);
target.add(bar);
}
In both cases this is impossible, however, from what I get from
this
discussion is that we want to make it magical that this is
possible.
It is no so much magical because you need to call the
setoutputmarkuptag(true) to do that and you can also revert it
when you
want calling
setoutputmarkuptag(false)
Either way, this is the next thing that comes up, right after
ListView
and Repeaters...
No problem because the default behavior is the same as today
(setoutputmarkuptag(false) by default)
And what do we do about components that are not visible because the
user is not authorized? Do we generate the tags or not?
With the last implementation coming out from our discuss is
If you explicitly called setoutputmarkuptag(true) on your bar
component
yes else no. So you can choose what you want to do?
The more I think about it, the more magic is needed, the less I
like
the idea.
Martijn
--
Vincent
Going from setVisible(false) to setVisible(true) does not work without surounding element
Hi, In the current implementation, going from setVisible(false) to setVisible(true) in ajax does not work, The current workaround of this bug is to surround the element with an other and to rerender the surounding element. I found this way not very smart and too frustating for the user. We actually need to surounding because nothing is render when setVisible is false. In https://issues.apache.org/jira/browse/WICKET-365 issue, I propose a fix. This fix will simply render a tag with an id and a style display:none. I don't think it is very expensive and works well with all browsers (IE, FF, Safari) and also in html table (often a problem in IE). With this patch it is possible to change the visibility of a component in a page without surounding it and adding it to the target. This issue has been tagged as won't fix, But I still think it is a good stuff For exemple a template(1) with foo.setVisible(false) and bar.setVisible(false) will be render as (2). See https://issues.apache.org/jira/secure/attachment/12353204/Component.patch.txt (1) div wicket:id=bar divInner/div plsdkqjlqkdsfj/p ... a lot of inner content /div table tr td /td /tr tr wicket:id=foo tdbla bla/td /tr /table (2) div id=bar0 style=display:none/div table tr td /td /tr tr id=foo1 style=display:none/tr /table I think this patch can make setVisible(false - true) in ajax smarter and more intuitive for user. WDYT?
Re: Going from setVisible(false) to setVisible(true) does not work without surounding element
Johan Compagner a écrit : But your patch doesn't do much with style i believe? It only generates a span tag where the component would be? Sorry I made a mistake in the attachement : Here is the right one https://issues.apache.org/jira/secure/attachment/12353648/component-real.txt Is that allowed every where? No it isn't allow in table for exemple Also always just rendering the component but use the style to make in invisible could be a security problem. So that can't be the default. What do you mean by security problem? But i do like to have some option where i can say render that span (if that is always possible) or use style johan On 3/19/07, Vincent Demay [EMAIL PROTECTED] wrote: Hi, In the current implementation, going from setVisible(false) to setVisible(true) in ajax does not work, The current workaround of this bug is to surround the element with an other and to rerender the surounding element. I found this way not very smart and too frustating for the user. We actually need to surounding because nothing is render when setVisible is false. In https://issues.apache.org/jira/browse/WICKET-365 issue, I propose a fix. This fix will simply render a tag with an id and a style display:none. I don't think it is very expensive and works well with all browsers (IE, FF, Safari) and also in html table (often a problem in IE). With this patch it is possible to change the visibility of a component in a page without surounding it and adding it to the target. This issue has been tagged as won't fix, But I still think it is a good stuff For exemple a template(1) with foo.setVisible(false) and bar.setVisible(false) will be render as (2). See https://issues.apache.org/jira/secure/attachment/12353204/Component.patch.txt (1) div wicket:id=bar divInner/div plsdkqjlqkdsfj/p ... a lot of inner content /div table tr td /td /tr tr wicket:id=foo tdbla bla/td /tr /table (2) div id=bar0 style=display:none/div table tr td /td /tr tr id=foo1 style=display:none/tr /table I think this patch can make setVisible(false - true) in ajax smarter and more intuitive for user. WDYT?
Re: Going from setVisible(false) to setVisible(true) does not work without surounding element
Johan Compagner a écrit : Also always just rendering the component but use the style to make in invisible could be a security problem. So that can't be the default. What do you mean by security problem? If the the component that is set to none visible is none visible because of security So it has data that never should be send to the browser because the user is not allowed to see it. But data is never send to the user because a none visible component will be render as an empty tag, so without data
Re: Going from setVisible(false) to setVisible(true) does not work without surounding element
Frédéric Bertin a écrit : Martijn Dashorst wrote: So you mean: Label l = Label(foo, hello); renders: span wicket:id=foohello/span ... some ajax stuff, or a normal page render: l.setVisible(false); renders: span wicket:id=foo style=display:none/span not @wicket:id, but just @id, because the Label should have setOutputMarkupId(true) to be refreshed with ajax Exactly, the goal of the id on a tag is to make wicket-ajax.js able to find it in the dom in order to replace it Fred
Re: Going from setVisible(false) to setVisible(true) does not work without surounding element
Martijn Dashorst a écrit : Currently everybody assumes (correctly) that the element is completely removed (Ajax and non-Ajax) Yes of course, but it is the same for all workarounds ;) When to change servlet to filter, users have to change their web xml. Each time you change something users have to adapt their code i.e. not present in the final markup. This means that scripts that iterate through the dom, or check for the document.getElementById() == null will fail if we implement this. it seems taht this kind of construction is used to make workaround of the bug. Is'n it? I *strongly* discourage changing this behavior. Martijn On 3/19/07, Matej Knopp [EMAIL PROTECTED] wrote: Will it? This seems to be actually quite a smart workaround. How exactly will this break existing clients? Only thing i'm concerned about is the validity of output markup. but imho when we preserve the original tag names, e.g. td will render as td, it should be all right. -Matej On 3/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote: So you mean: Label l = Label(foo, hello); renders: span wicket:id=foohello/span ... some ajax stuff, or a normal page render: l.setVisible(false); renders: span wicket:id=foo style=display:none/span ? This can and will break existing clients in a very nasty manner, because the markup id is still present in the final markup. Martijn On 3/19/07, Vincent Demay [EMAIL PROTECTED] wrote: Johan Compagner a écrit : Also always just rendering the component but use the style to make in invisible could be a security problem. So that can't be the default. What do you mean by security problem? If the the component that is set to none visible is none visible because of security So it has data that never should be send to the browser because the user is not allowed to see it. But data is never send to the user because a none visible component will be render as an empty tag, so without data -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
WICKET-365 - Go from setVisible(false) to setVisible(true) on a component in ajax does not work
I think it will be easier to speek about this in the mailing list ;) . I agree with the last comment : then why not simply adding the style=display:none attribute to the component tag, instead of creating an additional span ? but without its innnerHtml, only the componentTag. I think it should work in all case. -- Vincent Demay http://.demay-fr.net/blog/
Re: WICKET-365 - Go from setVisible(false) to setVisible(true) on a component in ajax does not work
Martijn Dashorst a écrit : I don't agree. style=display:none is not the same as not rendering it at all The text and markup is still available, it could have stuff that is sensitive in it. setVisible (false) should always remove the whole markup for the component from the stream. No, I think I wasn't very clear in what I said ;) . Generating an empty span is not very good because it could invalidate the xhtml, so just replacing the empty span tag with an *empty* component tag (div if it was a div, td if it was a td etc...) and display:none on it in order to not invalidate Xhtml could be fine imo. Ajax should work the same as normal requests. Otherwise what is the fricking point of having a AjaxFallbackLink? Yes it is a drag to add containers around your stuff that you want to hide. but it makes it explicit and predictable. Martijn On 3/7/07, Vincent Demay [EMAIL PROTECTED] wrote: I think it will be easier to speek about this in the mailing list ;) . I agree with the last comment : then why not simply adding the style=display:none attribute to the component tag, instead of creating an additional span ? but without its innnerHtml, only the componentTag. I think it should work in all case. -- Vincent Demay http://.demay-fr.net/blog/
Re: shutting down wicket-stuff lists?
+1 Eelco Hillenius a écrit : On 2/7/07, James McLaughlin [EMAIL PROTECTED] wrote: Agreed. +1 I only brought this up becuase some of us have been reluctant to create noise on the mailing lists, to the degree that we have contacted each other off list. If you can get there, ##wicket on freenode.net is a great way to reduce noise on the lists while still keeping more people involved. But for anything like making a decision and discussing things that could be good to have some history on, please *do* use these lists; it's what they are for! :) Eelco
Re: Fwd: [Wicket-stuff-develop] Dojo DragDrop
Eelco Hillenius a écrit : Forwarded from the wicket-stuff list. Eelco -- Forwarded message -- From: vsubedar [EMAIL PROTECTED] Date: Feb 3, 2007 3:50 AM Subject: [Wicket-stuff-develop] Dojo DragDrop To: wicket-stuff-develop@lists.sourceforge.net No drag-drop related files in wicket-contrib-dojo.jar from source-forge,net, and examples in http://www.demay-fr.net:8080/Wicket-start/app?wicket:bookmarkablePage=wicket-0:wicket.contrib.dojo.examples.OrderableList are pretty good but code not avilable! can any one help to get the code for those examples. New Wicket-contirb-dojo is not yet released. It will be done at same time as wicket 1.3. Sources are available on svn repo : https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff -- Vincent -- View this message in context: http://www.nabble.com/Dojo-DragDrop-tf3165633.html#a8781595 Sent from the wicket-stuff-develop mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-stuff-develop mailing list Wicket-stuff-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-stuff-develop
Re: replacement for date picker
Eelco Hillenius a écrit : And in case no-one is working on that anymore, what would be the best date picker (with a compatible licence!) to start working on? Dojo? YUI? ...? Hi, We've already done a datePicker in Dojo-Contrib (DojoDatePicker) with an apache compatible license. If you are interrested in it you can see a live demo here http://www.demay-fr.net:8080/WCD13/app?wicket:bookmarkablePage=%3Awicket.contrib.dojo.examples.DatePickerShower Eelco On 2/2/07, Eelco Hillenius [EMAIL PROTECTED] wrote: We decided to phase out extension's date picker a while ago. There was work being done by several people on a replacement. Where is that replacement in progress and how is the progress? Eelco
Re: adding a listener to the AjaxRequestTarget
Igor Vaynberg a écrit :
On 1/24/07, Vincent Demay [EMAIL PROTECTED] wrote:
if you _do_ need it to be called _during_ the rendering then we will
have to
extract an interface from the target that only has prependjavascript()
and
you will only get that in the listener instead of the target itself.
you means appendJavascript ?
yes, my bad :)
If we make a listener such as
IAjaxResponseListener {
[..]
sounds fine, do you need this in 2.0 only or 1.3 as well?
-igor
I need that in 2.0 and in 1.3 as weel, I'm currently writing this
I give you a patch as soon as I finish
Thanks
--
Vincent
Re: adding a listener to the AjaxRequestTarget
Ok it is done you could find a patch on jira :
http://issues.apache.org/jira/browse/WICKET-234
Thanks for your help Igor
Igor Vaynberg a écrit :
wonderful :)
-igor
On 1/24/07, Vincent Demay [EMAIL PROTECTED] wrote:
Igor Vaynberg a écrit :
On 1/24/07, Vincent Demay [EMAIL PROTECTED] wrote:
if you _do_ need it to be called _during_ the rendering then we
will
have to
extract an interface from the target that only has
prependjavascript()
and
you will only get that in the listener instead of the target
itself.
you means appendJavascript ?
yes, my bad :)
If we make a listener such as
IAjaxResponseListener {
[..]
sounds fine, do you need this in 2.0 only or 1.3 as well?
-igor
I need that in 2.0 and in 1.3 as weel, I'm currently writing this
I give you a patch as soon as I finish
Thanks
--
Vincent
adding a listener to the AjaxRequestTarget
Hi all, When I re-render a Dojo widget via an ajaxRequestTarget, I have to add some javascript to the request depending on which widget(component) has been added to the target. This javascript should be added in order to re-parse new DojoWidget (from the ajax response) with dojo API. This kind of parsing should only be done on top level Dojo component because during parsing sub-dojo-components will be automaticaly parsed. Actually what I need to do is : before sending response 1 - looking for all component added to the target 2 - for all top-level Dojo components : Adding its id to a map 3 - adding a js such as djConfig.searchIds = ['id1','id2','id3'];dojo.hostenv.makeWidgets(). My problem is I can not do a such stuff in a ajaxBehavior.respond because this should be done once by request and i do not have any access to the component list added to the target. On the other hand I can not extends AjaxRequestTarget because If i do that I can not use AjaxLink or other Ajax* to re-render a Dojo Component. So I thought to add a listener on AjaxRequestTarget that should be called after respondComponent in respondComponents method such as a IAjaxResponseListener with a onRender(Map/* String,Component */markupIdToComponent, AjaxRequestTarget target) method. Have you a better idea and WDYT about listener? thanks a lot -- Vincent
Re: Render a javascript in header via ajaxTarget
Matej Knopp a écrit :
I just tried it, 1.x and firefox. Works like charm for me :)
Are you sure you have caching turned of? The javascripts are cached
quite aggressively.
Ok, sorry to disturb you. I will check my sources.
Thanks
-Matej
Vincent Demay wrote:
Matej Knopp wrote:
That should work. I see no reason why ajax header contribution
should fail adding function. Do you use lastest wicket (any branch).
If so, can you please provide a quickstart app, so that I can look
at it?
Just try to put an alert('foo'); in a header contributor re-rendered
by ajax. When ajax response is evaluate no alert come out.
I work with lastest branch 1.X under Firefox
thanks
Render a javascript in header via ajaxTarget
Hi all, I add a new script (a new function that never been render before) in headerContributor tag of an ajaxTarget. After ajaxResponse, I tried to call this function but it seems it has not been defined (function x not defined) I took a look at wicket-ajax.js and processScript method. It seems the new function is just added to the header tag but never evaluated (with an eval or other). Is the fact to add a function dynamically via ajax in the header is sufficient to load the function définition? How can I call my new function added dynamically (A new function should be added on each ajax response)? thanks in advance,
Re: Render a javascript in header via ajaxTarget
Matej Knopp wrote:
That should work. I see no reason why ajax header contribution should
fail adding function. Do you use lastest wicket (any branch). If so,
can you please provide a quickstart app, so that I can look at it?
Just try to put an alert('foo'); in a header contributor re-rendered by
ajax. When ajax response is evaluate no alert come out.
I work with lastest branch 1.X under Firefox
thanks
--
Vincent
-Matej
Vincent Demay wrote:
Hi all,
I add a new script (a new function that never been render before) in
headerContributor tag of an ajaxTarget. After ajaxResponse, I tried
to call this function but it seems it has not been defined (function
x not defined)
I took a look at wicket-ajax.js and processScript method. It seems
the new function is just added to the header tag but never evaluated
(with an eval or other). Is the fact to add a function dynamically
via ajax in the header is sufficient to load the function définition?
How can I call my new function added dynamically (A new function
should be added on each ajax response)?
thanks in advance,
Render a javascript in header via ajaxTarget
Hi all, I add a new script (a new function that never been render before) in headerContributor tag of an ajaxTarget. After ajaxResponse, I tried to call this function but it seems it has not been defined (function x not defined) I took a look at wicket-ajax.js and processScript method. It seems the new function is just added to the header tag but never evaluated (with an eval or other). Is the fact to add a function dynamically via ajax in the header is sufficient to load the function définition? How can I call my new function added dynamically (A new function should be added on each ajax response)? thanks in advance, -- Vincent Demay
Re: RefreshingView and IDataProvider
Igor Vaynberg a écrit : what is the actual usecase? We select a row in a table on client side, this row matches to a list item(server side). This selection makes an ajax callback giving the item position. So We need to retrieve the item Model according to this position on server side. You can see DojoSelectableListContainer in WCD. This component uses a RefrechingView to display datas. -- Vincent -igor On 1/8/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Another request: we need to know the item at a given row position in the table for AJAX callbacks on selected rows. What is the best option to do that with a RefreshingView? Call iterator() and iterate until reaching the required index? Is there room for improvement on this? Wicket could provide a method for doing that maybe. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Dojo-contrib
Hi all, Dojo-wicket-contrib is now full of new features. So I have now 2 questions : How can I update wicket-dojo web site to make an annoucement of the future jar release? Are there relased date for Wicket 1.3 and wicket 2.0 Thanks -- Vincent
Re: wicket-stuff: [1117] trunk/wicket-contrib-dojo/src/main/java/ wicket/contrib/dojo
I think It's a good idea, js scripts will be easier to maintain and to
read. Where can I find samples of Velocity JavaScript templates uses?
Jean-Baptiste Quenot a écrit :
* [EMAIL PROTECTED]:
Log Message:
---
DragAndDrop Orderable listView
Modified:
trunk/wicket-contrib-dojo/src/main/java/wicket/contrib/dojo/dojodnd/DojoDropContainerHandler.java
===
---
trunk/wicket-contrib-dojo/src/main/java/wicket/contrib/dojo/dojodnd/DojoDropContainerHandler.java
2006-11-12 20:04:46 UTC (rev 1116)
+++
trunk/wicket-contrib-dojo/src/main/java/wicket/contrib/dojo/dojodnd/DojoDropContainerHandler.java
2006-11-14 18:26:19 UTC (rev 1117)
@@ -59,11 +59,7 @@
toReturn += var dl = byId(\ + container.getId() +
\);\n;
toReturn += var drop = new dojo.dnd.HtmlDropTarget(dl, [\ +
container.getDropId() + \]);\n;
toReturn += dojo.event.connect(drop, 'onDrop', function(e)
{\n;
- toReturn += dojo.io.bind({\n;
- toReturn +=url: createUrl(e),\n;
- toReturn +=mimetype:
\text/plain\,\n;
- toReturn +=load: function(type, data, evt)
{}\n;
- toReturn += });\n;
+ toReturn +=
dojoUpdate(createUrl(e),function(){},function(){},function(){},'');;
toReturn += });\n;
toReturn += }\n;
toReturn += dojo.event.connect(dojo, \loaded\, \initDrop +
container.getMarkupId() + \);\n;
Hi Vincent,
Great stuff, thanks!
However, in the future we will likely have more and more
JavaScript code embedded in Java classes.
What do you think if we introduced a dependency from
wicket-contrib-dojo to wicket-contrib-velocity to be able to use
Velocity JavaScript templates instead of ugly and inefficient
String concatenations?
--
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/
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/
Why rewriting js libraries
Hello, 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
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
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
