Re: Struts Ti - yes, again ;)

My design preference for things like this (as is playing out in Struts 1.3) is to define a single scoped bean which can contain any references like this, so as to sharply minimize the need for constants like this. If you do that, then you're down to a single constant to use to retrieve that be

Re: [shale] status

Craig McClanahan wrote: Thanks for the pointer ... I wasn't aware of that. That being said, it's not clear that a lot of effort should be devoted to the Shale Ant scripts, since Wendy has volunteered to Mavenize them (as long as she can deal with the either-JSF-RI-or-MyFaces requirements -- boy

Re: Struts Ti doubt

On 8/29/05, Don Brown <[EMAIL PROTECTED]> wrote: > > netsql wrote: > > > Can we add iBatis DAO to Ti (not iBatis Implemnation or SQL MAPs, just > > DAO). It would reduce # of user questions. > > Using iBatis DAO, people can implement the DAO anyway (or they could > > replace the iBatis DAO). > >

Re: Struts Ti - yes, again ;)

On 8/31/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > > My design preference for things like this (as is playing out in > Struts 1.3) is to define a single scoped bean which can contain any > references like this, so as to sharply minimize the need for > constants like this. If you do that, then y

Re: Struts Ti - yes, again ;)

At 9:40 AM -0400 8/31/05, Ted Husted wrote: On 8/31/05, Joe Germuska <[EMAIL PROTECTED]> wrote: My design preference for things like this (as is playing out in Struts 1.3) is to define a single scoped bean which can contain any references like this, so as to sharply minimize the need for co

DO NOT REPLY [Bug 36439] New: - [shale] Allow user to supply their own Dialog DTD

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Struts Ti - yes, again ;)

I actually agree that a single bean is better than a lot of separate values under various keys. In Beehive we put most of our request-scoped values onto a request wrapper -- this turned out to have better performance than doing the attribute lookup all over the place. But it's a similar idea.

DO NOT REPLY [Bug 36441] New: - bean:include does not work properly on WAS6

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: [shale] status

I see that Wendy is using Maven 1.x. Are there any plans to move it to Maven 2? Jeremy J. Barth -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 8:20 AM To: dev@struts.apache.org Subject:Re: [shale] status Craig McCl

DO NOT REPLY [Bug 36441] - bean:include does not work properly on WebSphere Application Server v6

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36439] - [shale] Allow user to supply their own Dialog DTD

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Struts Ti - yes, again ;)

On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > I actually agree that a single bean is better than a lot of separate > values under various keys. In Beehive we put most of our request-scoped > values onto a request wrapper -- this turned out to have better > performance than doing the attribu

Re: Struts Ti - yes, again ;)

Craig McClanahan wrote: On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote: I actually agree that a single bean is better than a lot of separate values under various keys. In Beehive we put most of our request-scoped values onto a request wrapper -- this turned out to have better performance than

Re: Struts Ti doubt

Ted Husted wrote: I'd suggest showing how to hook up to iBATIS or HIbernate in an example application, and then deciding if TI needs to create yet-another DAO framework. Many iBATIS user s have stopped using the iBATIS DAO framework, since they find using a dependency-injection framework, l

Re: Struts Ti - yes, again ;)

Craig McClanahan wrote: On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote: I actually agree that a single bean is better than a lot of separate values under various keys. In Beehive we put most of our request-scoped values onto a request wrapper -- this turned out to have better performance

Re: Struts Ti - yes, again ;)

Passing in a context CoR style lets it be used in other contexts, not planed for originaly, and lets you make chains not designed for. .V Don Brown wrote: Still, I'm not convinced everything can/should fall under one Context. For example, XWork has a ValidationContext which I think we shoul

Re: Struts Ti - yes, again ;)

Don Brown wrote: Craig McClanahan wrote: On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote: I actually agree that a single bean is better than a lot of separate values under various keys. In Beehive we put most of our request-scoped values onto a request wrapper -- this turned out to have be

Re: Struts Ti doubt

On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote: > > You might also be interested in the Spring and Chain integration piece I > wrote for Ti. We just load the Commands and Chains with Spring, along with everything else, and don't bother with a separate catalog. It started out ugly, but if y

Re: Struts Ti doubt

(Mouse slipped) On 8/31/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > > We also do things like create base data-access commands that know how to > run iBATIS > > -Ted. > > We also do things like create base data-access commands that know how to run iBATIS queries. If a data-access command

Spring and Chain (was Struts Ti doubt)

Hmm...I like the idea of combining the configurations from a maintenance point of view, but on the other hand, the flow chain can get lost, particularly when the number of commands are in a minority. Separating also has the benefit, in our case anyways, of having the chain stay generic, but Spri

Spring and Chain (was Struts Ti doubt)

Very interesting. Do you have any examples/tutorials of this anywhere accessible? Don Ted Husted wrote: (Mouse slipped) On 8/31/05, Ted Husted <[EMAIL PROTECTED]> wrote: We also do things like create base data-access commands that know how to run iBATIS -Ted. We also do things lik

Re: Struts Ti - yes, again ;)

On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > > Using JSF is actually what convinced me that having the context on > ThreadLocal is a great thing. It really cleans up the APIs. (Nice job > BTW :) ). Our ActionContext will give us something similar... but I do > wonder about "internal" attr

Re: [shale] status

Have you tried Maven 2? Being a Maven evangelist myself, I have followed along with the announcements and I even have the latest beta installed on my box, but I haven't had much of a chance to play with it. I just wonder how complete the plugins are for it. Maven 1.x has had a long time

RE: [shale] status

I haven't tried Maven 2 either. Shale would be a good kick in the butt to learn though! According to their website, it looks like they're almost ready for a beta release. The current release is Alpha 3. I was at the BoF session at JavaOne on Maven this year. They were confident about port

Re: Spring and Chain (was Struts Ti doubt)

At 10:10 AM -0700 8/31/05, Don Brown wrote: Hmm...I like the idea of combining the configurations from a maintenance point of view, but on the other hand, the flow chain can get lost, particularly when the number of commands are in a minority. Separating also has the benefit, in our case anywa

Re: Struts Ti - yes, again ;)

Craig McClanahan wrote: On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote: Using JSF is actually what convinced me that having the context on ThreadLocal is a great thing. It really cleans up the APIs. (Nice job BTW :) ). Our ActionContext will give us something similar... but I do wonder ab

Re: Spring and Chain (was Struts Ti doubt)

Joe Germuska wrote: I've just recently started getting my head around Spring's approach to nested BeanFactories (or ApplicationContexts) and I'm wondering if that isn't a better bootstrap mechanism than the explicit instantiation of an XmlBeanFactory. It seems more likely to support a mixture

Re: Spring and Chain (was Struts Ti doubt)

This also makes it fairly trivial to break out Struts' own XML configuration into multiple files, so that there could be a "chain-config.xml" file which adhered to the spring-beans.dtd instead of using Digester. Sure, sounds like a good approach; I'll look into it. I'm pretty new to Spring a

Re: Spring and Chain (was Struts Ti doubt)

Great, I like it! The XWork messages are only for the user and not used by Ti internally at all. If using the ApplicationContext doesn't impact the user negatively, I'm all for it. The earliest I could make these changes would be next week, but if you are volunteering... :) Don Joe Germuska

Spring and XWork in Ti (was: Spring and Chain (was Struts Ti doubt))

So, I really do have work I should be doing, but I couldn't help looking around XWork a little bit, and I'm just wondering why Ti needs to use both it and Spring anyway? What are the various services offered by each that aren't offered by the other? Joe At 2:44 PM -0500 8/31/05, Joe Germuska

Re: Spring and Chain (was Struts Ti doubt)

On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote: > > Very interesting. Do you have any examples/tutorials of this anywhere > accessible? That's where the OverDrive/Nexus stuff is going, but, lately, the volunteer hours have been going into Struts Classic :) I'm doing some major refactoring

Re: Spring and XWork in Ti

Joe Germuska wrote: So, I really do have work I should be doing, but I couldn't help looking around XWork a little bit, and I'm just wondering why Ti needs to use both it and Spring anyway? What are the various services offered by each that aren't offered by the other? I should really list

Fwd: [shale] Why does data disappear when terminating?

Oops. Sent to MyFaces instead of Struts. Sorry. -- Forwarded message -- From: Sean Schofield <[EMAIL PROTECTED]> Date: Aug 31, 2005 5:37 PM Subject: [shale] Why does data disappear when terminating? To: MyFaces Development Craig, I was wondering about the decision to "pop" t

Re: [shale] Why does data disappear when terminating?

On 8/31/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Oops. Sent to MyFaces instead of Struts. Sorry. > > -- Forwarded message -- > From: Sean Schofield <[EMAIL PROTECTED]> > Date: Aug 31, 2005 5:37 PM > Subject: [shale] Why does data disappear when terminating? > To: MyFaces

svn commit: r265608 - /struts/site/trunk/xdocs/userGuide/release-notes.xml

Author: husted Date: Wed Aug 31 17:57:54 2005 New Revision: 265608 URL: http://svn.apache.org/viewcvs?rev=265608&view=rev Log: A few more notes. Modified: struts/site/trunk/xdocs/userGuide/release-notes.xml Modified: struts/site/trunk/xdocs/userGuide/release-notes.xml URL: http://svn.apach

svn commit: r265660 - in /struts/core/branches/STRUTS_1_2_BRANCH/src/test/org/apache/struts/tiles: ./ config/

Author: niallp Date: Wed Aug 31 23:00:54 2005 New Revision: 265660 URL: http://svn.apache.org/viewcvs?rev=265660&view=rev Log: Add new tile I18nFactorySet test files Added: struts/core/branches/STRUTS_1_2_BRANCH/src/test/org/apache/struts/tiles/TestI18nFactorySet.java (with props) st

svn commit: r265661 - in /struts/tiles/trunk/src: java/org/apache/struts/tiles/xmlDefinition/ test/org/apache/struts/tiles/ test/org/apache/struts/tiles/config/

Author: niallp Date: Wed Aug 31 23:03:26 2005 New Revision: 265661 URL: http://svn.apache.org/viewcvs?rev=265661&view=rev Log: Remove I18nFactorySet copied code - highlighted by Sam Ruby Added: struts/tiles/trunk/src/test/org/apache/struts/tiles/TestI18nFactorySet.java (with props) st

svn commit: r265659 - in /struts/shale/trunk: -project.xml build.properties.sample core-library/project.xml jsfri-project.xml maven.xml myfaces-project.xml project.properties project.xml use-cases/mav

Author: wsmoak Date: Wed Aug 31 22:59:36 2005 New Revision: 265659 URL: http://svn.apache.org/viewcvs?rev=265659&view=rev Log: Reworked the Maven build files for Shale - Modified myfaces-project.xml and added jsfri-project.xml as top-level project files that express dependencies on a particular

svn commit: r265658 - in /struts/core/branches/STRUTS_1_2_BRANCH: build-tests.xml src/share/org/apache/struts/tiles/xmlDefinition/I18nFactorySet.java src/test/org/apache/struts/tiles/TestTilesPlugin.j

Author: niallp Date: Wed Aug 31 22:54:57 2005 New Revision: 265658 URL: http://svn.apache.org/viewcvs?rev=265658&view=rev Log: Remove I18nFactorySet copied code - highlighted by Sam Ruby Modified: struts/core/branches/STRUTS_1_2_BRANCH/build-tests.xml struts/core/branches/STRUTS_1_2_BRAN

svn commit: r265662 - /struts/sandbox/trunk/tiles/src/java/org/apache/tiles/xmlDefinition/I18nFactorySet.java

Author: niallp Date: Wed Aug 31 23:25:43 2005 New Revision: 265662 URL: http://svn.apache.org/viewcvs?rev=265662&view=rev Log: Remove I18nFactorySet copied code - highlighted by Sam Ruby Modified: struts/sandbox/trunk/tiles/src/java/org/apache/tiles/xmlDefinition/I18nFactorySet.java Modifie

[Struts Wiki] Trivial Update of "StrutsTi" by DonBrown

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsTi -- == Links ==

[Struts Wiki] Update of "StrutsTi" by DonBrown

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsTi -- '''Struts Ti