[tiles2] Changes in tag libraries
Hi As you may have seen, I replace tag with three specialized tags: , , . I hope you don't hate me for the change :-) I thought that an eventual is useless, since there are better tags to put strings. Notice that you can still "insert" (or better "define") attributes of string type, by using . I applied the changes also to the test webapp, so you can see if the code is clearer (or not :-) ). I added also a FAQ entry describing the change. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
Correct, I've got a patch prepared and will commit it once I deploy the new tiles snapshot - just got my unix perms yesterday. David Antonio Petrelli wrote: Wendy Smoak ha scritto: Looks like Struts 2 doesn't build against the latest Tiles 2... [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\svn\struts\struts2-base\plugins\tiles\src\main\java\org\apache\struts2\views\ tiles\TilesResult.java:[123,24] setContext(org.apache.tiles.ComponentContext,org .apache.tiles.TilesRequestContext) in org.apache.tiles.ComponentContext cannot b e applied to (org.apache.tiles.ComponentContext,org.apache.tiles.TilesContext) c:\svn\struts\struts2-base\plugins\tiles\src\main\java\org\apache\struts2\views\ tiles\TilesResult.java:[176,51] getContext(org.apache.tiles.TilesRequestContext) in org.apache.tiles.ComponentContext cannot be applied to (org.apache.tiles.Til esContext) c:\svn\struts\struts2-base\plugins\tiles\src\main\java\org\apache\struts2\views\ tiles\TilesResult.java:[179,28] setContext(org.apache.tiles.ComponentContext,org .apache.tiles.TilesRequestContext) in org.apache.tiles.ComponentContext cannot b e applied to (org.apache.tiles.ComponentContext,org.apache.tiles.TilesContext) See http://issues.apache.org/struts/browse/SB-44 - TilesContext has been, in synthesis, renamed in TilesRequestContext. c:\svn\struts\struts2-base\plugins\tiles\src\main\java\org\apache\struts2\views\ tiles\TilesResult.java:[197,25] cannot find symbol symbol : method getOrCreateController() location: class org.apache.tiles.ComponentDefinition See http://issues.apache.org/struts/browse/SB-54 - Controller has been renamed to ViewPreparer, and the method "getOrCreateController" has been renamed to "getOrCreatePreparer". Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.1 missing from people.apache.org?
In the meantime, we've made the binaries available via SoruceForge. * http://www.planetstruts.org/roller/page/news?entry=struts_2_0_1_jars I was going to try and submit this for mirroring last night (even that's even possible right now), but spent the time on our Confluence woes instead :( * http://issues.apache.org/jira/browse/INFRA-1002 -Ted. On 10/26/06, James Mitchell <[EMAIL PROTECTED]> wrote: That's because the Apache Infra team is still working on the servers. We only have data up to a few weeks ago or so. I wish I had a link to point people to for more info, sorry. Just keep checking back. -- James Mitchell 678.910.8017 On Oct 26, 2006, at 10:49 AM, Matt Raible wrote: > This issue will likely go away when 2.0.1 gets uploaded to ibiblio - > however, 2.0.1 was available at the following URL last week, now it's > gone. > > http://people.apache.org/maven-snapshot-repository/org/apache/ > struts/struts2-core/ > > Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
On Oct 27, 2006, at 6:40 AM, David H. DeWolf wrote: Correct, I've got a patch prepared and will commit it once I deploy the new tiles snapshot - just got my unix perms yesterday. What happened? Is the TilesResult dependent on a snapshot or nightly build or what? I would hope we could make changes like this without breaking people until the changes are done. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory refactor)
On Oct 26, 2006, at 8:03 AM, David H. DeWolf wrote: I'll probably have some time to finish up the TilesContextFactory configuration today and start doing some work on removing duplication. Once I get through that I'll start putting some container ideas down into code. The first step of that process will be to define the tiles container api. What are those things that we want to expose to the world? It doesn't seem like much. The majority of what people will do with Tiles is plug it into another architecture, so we need to focus on the points where it interfaces with MVC architectures I think. Beyond that, there will be cases where people want to create, modify, and access definitions and attributes. I'd say keep the public API as small as possible and add to it as requests come in. Antonio may have more input since he's working with some Tiles extensions. Do we prefer to do the container work in a branch, or continue working on it in the trunk? Either way is fine with me. I would prefer to just do it in the trunk since it can be done incrementally. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
On 10/27/06, Greg Reddin <[EMAIL PROTECTED]> wrote: What happened? Is the TilesResult dependent on a snapshot or nightly build or what? I would hope we could make changes like this without breaking people until the changes are done. Yes, Struts 2 depends on a snapshot of Tiles 2. So does Shale. And I published Tiles snapshots last night. IMO, people depending on a snapshot of a sandbox project should be prepared for this sort of thing, so I don't consider it a big problem. We might want to switch to timestamped snapshots (remove the uniqueVersion=false in the pom) so that projects can choose when to move up to the latest bits. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
Yes, TilesResult is dependent on the snapshot (the published snapshot). The struts2 build will fail, if and only if, you build tiles locally against the trunk and then build struts2 against the trunk. I have a patch ready to apply to struts2, but in order to do that, I need to be able to publish the new tiles snapshot so that it's available for those people that don't built tiles. I just got unix permissions to do so yesterday, and hope to get to it today. Since we are changing tiles and flushing out the 2.0 api, I don't think we can prevent this type of failure for people that use snapshots. The current failure comes from 2 things: the view preparer changes that were made and the tiles context changes that were made. I really don't see it as a big deal, because that's precisely what a snapshot is, an instable artifact that captures the state of the code base at a certain point of time. This is a great reason to drive towards an initial release :) David Greg Reddin wrote: On Oct 27, 2006, at 6:40 AM, David H. DeWolf wrote: Correct, I've got a patch prepared and will commit it once I deploy the new tiles snapshot - just got my unix perms yesterday. What happened? Is the TilesResult dependent on a snapshot or nightly build or what? I would hope we could make changes like this without breaking people until the changes are done. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
Wendy Smoak wrote: On 10/27/06, Greg Reddin <[EMAIL PROTECTED]> wrote: What happened? Is the TilesResult dependent on a snapshot or nightly build or what? I would hope we could make changes like this without breaking people until the changes are done. Yes, Struts 2 depends on a snapshot of Tiles 2. So does Shale. And I published Tiles snapshots last night. Oh Good! I'll get the patch in then. IMO, people depending on a snapshot of a sandbox project should be prepared for this sort of thing, so I don't consider it a big problem. We might want to switch to timestamped snapshots (remove the uniqueVersion=false in the pom) so that projects can choose when to move up to the latest bits. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
On Oct 27, 2006, at 9:52 AM, Wendy Smoak wrote: On 10/27/06, Greg Reddin <[EMAIL PROTECTED]> wrote: What happened? Is the TilesResult dependent on a snapshot or nightly build or what? I would hope we could make changes like this without breaking people until the changes are done. Yes, Struts 2 depends on a snapshot of Tiles 2. So does Shale. And I published Tiles snapshots last night. Ok, that's cool. So I suppose I need to fix Shale too, huh? :-) We might want to switch to timestamped snapshots (remove the uniqueVersion=false in the pom) so that projects can choose when to move up to the latest bits. That might be a better ides. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
On Oct 27, 2006, at 9:58 AM, David H. DeWolf wrote: Since we are changing tiles and flushing out the 2.0 api, I don't think we can prevent this type of failure for people that use snapshots. The current failure comes from 2 things: the view preparer changes that were made and the tiles context changes that were made. Yes, and the only 2 projects currently using Tiles 2 are Struts 2 and Shale and between the two of us we have committer rights to change both so I'm not too worried about it. It will encourage us to get the release out :-) This is a great reason to drive towards an initial release :) What you said ;-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT][Friday] Free Struts Seminar with James Holmes - London
[OT][Friday] Free Struts Session - London Skills Matter, the Open Source Technology training company, is hosting a free In-the-Brain session featuring James Holmes,Struts project committer, creator of Struts Console and author of Struts: The Complete Reference Guide. During this session James will introduce Struts Scripting and how to use it, additonally, a live demo will be shown on creating Struts actions using the Groovy Scripting language. For more information or to reserve your spot, please go to: http://skillsmatter.com/struts-in-the-brain-session-11-2006 Struts Training James, will also be presenting a Struts Training course at Skills Matter in London from 28th November - 1st December. The course is entitled: Developing Applications with Apache Struts. For more information or to book your seat, please go to: http://skillsmatter.com/apache-struts-course -- Lauren Clegg Marketing t 0207 1072620 f 0207 1072621 e [EMAIL PROTECTED] Skills Matter In the Brain Sessions! In The Brain - of Kito Mann: Free seminar on Ajax Development with JavaServer Faces - November 13th In The Brain - of Paul Fremantle: Free seminar on SOA with Apache Axis2 & Web Services - November 28th In The Brain - of Peter Delia: Free seminar on Mule the Lightweight Messaging Framework - November 30th Skills Matter Ltd 1 Sekforde Street London, EC1R 0BE United Kingdom Map
Re: parameters on ajax calls
If you are talking about the server-side tags, then yes, you can add
parameters, but by using a child tag under the element.
Don
Musachy Barroso wrote:
I was thinking in adding an attribute to the ajax tags, "parameters",
which
will be evaluated before the request is made, so parameters with current
values can be passed. Something like
... href="/foo.action" parameters="value={selectId}&bb=cc" ..
the url for the request would be:
/foo.action?value=bar&bb=cc
where "bar" is the value of the element with id "selectId". I find
strange
this was requested before, could there be a bug in jira for this?
musachy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: parameters on ajax calls
This parameters will be evaluated by javascript on the client side, just
before the request is made. Are we talking about the same thing?
musachy
Don Brown wrote:
If you are talking about the server-side tags, then yes, you can add
parameters, but by using a child tag under the element.
Don
Musachy Barroso wrote:
I was thinking in adding an attribute to the ajax tags, "parameters",
which
will be evaluated before the request is made, so parameters with current
values can be passed. Something like
... href="/foo.action" parameters="value={selectId}&bb=cc" ..
the url for the request would be:
/foo.action?value=bar&bb=cc
where "bar" is the value of the element with id "selectId". I find
strange
this was requested before, could there be a bug in jira for this?
musachy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: parameters on ajax calls
Perhaps not...could you back up and explain the use case?
Don
Musachy Barroso wrote:
This parameters will be evaluated by javascript on the client side,
just before the request is made. Are we talking about the same thing?
musachy
Don Brown wrote:
If you are talking about the server-side tags, then yes, you can add
parameters, but by using a child tag under the element.
Don
Musachy Barroso wrote:
I was thinking in adding an attribute to the ajax tags,
"parameters", which
will be evaluated before the request is made, so parameters with
current
values can be passed. Something like
... href="/foo.action" parameters="value={selectId}&bb=cc" ..
the url for the request would be:
/foo.action?value=bar&bb=cc
where "bar" is the value of the element with id "selectId". I find
strange
this was requested before, could there be a bug in jira for this?
musachy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: parameters on ajax calls
Suppose there is an action "foo.action" that we want to call using an
ajax request, and we want to pass as a paratemer to the action the
current value of a text input field. The jsp would be something like:
parameters="value={sometext}" refreshListenTopic="/refresh">
Now, you type "test" on the textbox, and you force the div to refresh;
"parameters" will be expanded to "value=test", and the url for the
request will be: "foo.action?value=test". So we can pass user
entered/selected data to the action.
musachy
Don Brown wrote:
Perhaps not...could you back up and explain the use case?
Don
Musachy Barroso wrote:
This parameters will be evaluated by javascript on the client side,
just before the request is made. Are we talking about the same thing?
musachy
Don Brown wrote:
If you are talking about the server-side tags, then yes, you can add
parameters, but by using a child tag under the element.
Don
Musachy Barroso wrote:
I was thinking in adding an attribute to the ajax tags,
"parameters", which
will be evaluated before the request is made, so parameters with
current
values can be passed. Something like
... href="/foo.action" parameters="value={selectId}&bb=cc" ..
the url for the request would be:
/foo.action?value=bar&bb=cc
where "bar" is the value of the element with id "selectId". I find
strange
this was requested before, could there be a bug in jira for this?
musachy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Strecks (Struts extensions for Java 5) version 1.0 released
I'm pleased to announce the release of Strecks 1.0. Strecks is a set of Java 5-specific extensions to the original Struts framework. Making heavy use of Java 5 annotations, it adds a number of modern features to Struts-based applications, including POJO actions, dependency injection, declarative validation and data binding, interceptors, pluggable views, as well as seamless Spring integration. It is also highly extensible and amenable to test driven development. For more information, see http://strecks.sourceforge.net/features.php. The aim of Strecks has been to address the most widely perceived inadequacies of the original Struts programming model while still allowing full backward compatibility of applications. Strecks works with the most recent general availability Struts versions (1.2.8 and 1.3.5), but at the same time allows developers to work with advanced features expected from modern web frameworks. Strecks offers an enhanced programming model for actions and forms, while working with existing unchanged templating and configuration mechanisms. Strecks is aimed at developers who: - have a significant existing investment in the current version of Struts, either in terms of knowledge or existing code - are not currently ready or willing to take the pain of migrating to the forthcoming Struts 2.0 (based on WebWork) or another web framework - want to take advantage of advanced features not available in vanilla Struts but increasingly so in other frameworks Strecks can be downloaded from http://strecks.sourceforge.net/download.php. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts-Faces] possible Bug in FormRenderer
Hey, two things. a) is this the right place to ask questions on Struts-Faces, or where ? if so b) the demos of struts faces show a "portal" which uses links (done w/ JSF-components) to navigate to a tiles pages, which finally contains a based formular. that is the key... ActionForm/Action on the java side and JSF comp.s on the page side. Every thing works. A form-submit sends a req. to the action So far so good... When I am converting one of my own apps w/ struts-faces I'd like to stay with for linking to form pages (that are using ). But ... since that is a GET request the form renders html like (only when using GET / html:link) so ... a submit causes a 404. Not wondering :) When I use firebug to change the action attr value to /blub/tilesMasterLayout.faces every thing works. Action is called. The action() method in FormRenderer returns in the wrong szenario a .do URL I think it is not to bad to check agains a struts pattern in that URL and replace that .do (if needed) with the jsf pattern (like .faces or add /faces/) I think this is valid, because the form renders already fine, which ensures you are inside the FacesContext ... If you all agree, I'd like to provide the patch for that. Greetz, Matt -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Struts 2 Result Selectors
Well, my original purpose is to find a way to best handle the case where we want to generate multiple types of output without the Action being aware of it. Foremost in my mind is the ability to have an action be called and expect HTML, partial HTML, or JSON without affecting the Action. Whether it is easy for the end user to add their own result selectors or not is secondary. In fact, there would be much fewer times that you would want to implement your own, so I'm fine putting it in struts.properties along with the other factories. Don David H. DeWolf wrote: Gotcha! I see what you mean and how they differ. My off-the-cuff thought was that: 1) no, I envisioned result-selector elements at the global and/or package level. 2) multiple selectors would be invoked until the first match is made (not sure this is ideal). Perhaps it's best to back up and look at the actual requirement (I was originally guessing at your thoughts as opposed to suggesting an approach). I should have just asked the question, as I obviously didn't really think through my stab in the dark: - End users should have the ability to implement and deploy new selectors in a manner which is consistent with the way they implement and deploy interceptors and actions. David Don Brown wrote: What I mean is, with interceptors, you define them, but it is only when you add them to an action are they actually used. Do you envision a element going in every action, except when a is defined for a package? How do you handle multiple selectors? A selector chain? You'd still have these problems with interceptors. How do you define the chain of selectors with annotations at a global level? Don David H. DeWolf wrote: If we used the element, how would you define multiple ones? Just repeating the element wouldn't match the style of other configuration elements. How would this look as one or more annotations? Really? Seems similar to me. I'm not suggesting that the result-selector would replace the when attribute, instead, I'm suggesting that we mimic: with: foo.jsp foo-ns4.jsp This basically allows for custom selectors to be registered. Like you say, if they do not need to be scoped at the package/action level, then you could definitely achieve the same thing with struts.properties (pending the discussion of: https://issues.apache.org/struts/browse/WW-1421). It's really not a big deal, as long as I do have the ability to register new implementations. My preference would be for that configuration to be in the same location as where I specify all the other custom components I've developed - either as attributes or in struts.xml. As far as attributes go, they render the configuration irrelevant. Am I missing something? @Selector would simply replace the result-selector configuration. @Result(name="success", when="modern-browser") would replace the . David Don David Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: parameters on ajax calls
Hmm..ok, I see your point, however, perhaps we are pushing too much onto
the div tag. Is there another approach which would make it easier to
grasp at a glance what we are trying to do?
Don
Musachy Barroso wrote:
Suppose there is an action "foo.action" that we want to call using an
ajax request, and we want to pass as a paratemer to the action the
current value of a text input field. The jsp would be something like:
parameters="value={sometext}" refreshListenTopic="/refresh">
Now, you type "test" on the textbox, and you force the div to refresh;
"parameters" will be expanded to "value=test", and the url for the
request will be: "foo.action?value=test". So we can pass user
entered/selected data to the action.
musachy
Don Brown wrote:
Perhaps not...could you back up and explain the use case?
Don
Musachy Barroso wrote:
This parameters will be evaluated by javascript on the client side,
just before the request is made. Are we talking about the same thing?
musachy
Don Brown wrote:
If you are talking about the server-side tags, then yes, you can
add parameters, but by using a child tag under the element.
Don
Musachy Barroso wrote:
I was thinking in adding an attribute to the ajax tags,
"parameters", which
will be evaluated before the request is made, so parameters with
current
values can be passed. Something like
... href="/foo.action" parameters="value={selectId}&bb=cc" ..
the url for the request would be:
/foo.action?value=bar&bb=cc
where "bar" is the value of the element with id "selectId". I find
strange
this was requested before, could there be a bug in jira for this?
musachy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax tags
Yes, let's start with bumping up Dojo to 0.4, then apply patches to
update the tags. How much work do you think it'll be to upgrade Dojo?
Don
Musachy Barroso wrote:
I attached a new patch to WW-205, this one includes the new
TabbedPanel, BindDiv and BindAnchor. It needs Dojo 0.3.1.Do you want
me to create a patch to update to Dojo 0.3.1?(We just need to replace
dojo distribution under static/dojo.)
I modified the examples in showcase and the test cases. Let me know if
something is missing or wrong (bear with me on my first patch :) ).
musachy
Don Brown wrote:
Ok, then put those two under one ticket. You know best :)
Don
Musachy Barroso wrote:
That's ok, the only problem is that this one by itself would break
anchor and tabbed panel.
musachy
Don Brown wrote:
I'd prefer separate issues, with attached patches. As for testing,
we started to use Patrick's hostedqa stuff, but we need to use it
more.
Don
Musachy Barroso wrote:
I have everything (I think :)) for the ajax Div Tag, do you want
me to create a patch for it, or wait and create a big one when I'm
done with the other widgets (anchor, tree...dojo 0.2 -> 0.3)?
musachy
//Have you guys consider anything to test this ajax stuff?
(Selenium maybe?)
Musachy Barroso wrote:
This was with 0.3.1 which is the current release. I posted a
message on their mailing list.
musachy
Don Brown wrote:
Have you tried this with the Dojo 0.4 release? Any reason we
shouldn't upgrade to it?
Don
Musachy Barroso wrote:
Would something like this include all the current functionality
in BindDiv? (events for stop/start timer, refresh, start after
a delay, advisor via dojo's "handler" property). This way
BindDiv will be easier to maintain (dojo's ContentPane + timer)
and the Tab widget can be deleted (doesn't add anything to this
one). By the way this doesn't work on AMD 64/firefox/linux due
to a dojo's bug.
dojo.provide("struts.widgets.BindDiv");
dojo.require("dojo.widget.*");
dojo.require("dojo.io.*");
dojo.require("dojo.widget.Container");
dojo.require("dojo.widget.ContentPane");
dojo.require("dojo.animation.Timer");
struts.widgets.BindDiv = function() {
dojo.widget.html.ContentPane.call(this);
var self = this;
this.widgetType = "BindDiv";
this.href = "";
this.extractContent = false;
this.parseContent = false;
this.cacheContent = false;
this.frequency = 0;
this.delay = 0;
this.startTimer = false;
this.timer = null;
//pub/sub events
this.refreshListenTopics = "";
this.stopTimerListenTopics = "";
this.startTimerListenTopics = "";
this.postCreate = function() {
if(self.frequency > 0) {
self.timer = new dojo.animation.Timer(self.frequency);
self.timer.onTick = self.reloadContents;
//start the timer
if(self.startTimer) {
//start after delay
dojo.debug("starting timer after " + self.delay);
dojo.lang.setTimeout(self.delay, self.startTimer);
}
}
//attach listeners
if(!dojo.string.isBlank(self.refreshListenTopics)) {
dojo.debug("Listening to " + self.refreshListenTopics);
dojo.event.topic.subscribe(self.refreshListenTopics, self,
"reloadContents");
}
if(!dojo.string.isBlank(self.stopTimerListenTopics)) {
dojo.debug("Listening to " + self.stopTimerListenTopics);
dojo.event.topic.subscribe(self.stopTimerListenTopics,
self, "stopTimer");
}
if(!dojo.string.isBlank(self.startTimerListenTopics)) {
dojo.debug("Listening to " + self.startTimerListenTopics);
dojo.event.topic.subscribe(self.startTimerListenTopics,
self, "startTimer");
}
};
this.reloadContents = function() {
//refresh is not visible in ContentPane
self.isLoaded = false;
self.loadContents();
};
this.stopTimer = function() {
dojo.debug("stopping timer");
self.timer.stop();
};
this.startTimer = function() {
dojo.debug("starting timer with frequency " + self.frequency);
self.timer.start();
};
};
dojo.inherits(struts.widgets.BindDiv,
dojo.widget.html.ContentPane);
dojo.widget.tags.addParseTreeHandler("dojo:BindDiv");
Musachy Barroso wrote:
I was looking at the Div/Panel classes and I think we need to
do some changes, right now Panel extends Div and PanelTag
exteds DivTag. The problem is that the new PanelTag wraps
dojo's ContentPane, while DivTag wraps HTMLBindDiv(from
struts), and they are quite different. I think we should
replace HTMLBindDiv with an implementation that extends dojo's
ContentPane and add a timer to it for the auto refresh.
what do you guys think?
musachy
Ian Roughley wrote:
Yes - this was the direction that we wanted to go in. Try to
do as much as possible in dojo and provide light wrappers in
Struts. When we first implemented the tabs, there was no
such dojo implementation. The one feature that we had that
you should check that has been implemented in dojo is the
pub/sub events - so there should be events that each tabs
listens to to refresh itself.
I think as Don pointed out, we
[Struts-Faces] commandLink obsolete ?
commandLink was create in 2004, b/c of a RI bug. I guess (or assume) that it has been fixed there. works fine w/ MyFaces. however inside trinidad/adf the commandLink will not work ... -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
