Re: 1.3.5 on website?
On 8/1/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: It isn't on the mirrors yet, and hasn't been announced, so the website hasn't been updated. I think only the signatures remain to be done, then everything can be deployed to the mirrored directories. That's true, but looking over my schedule, I have no discretionary time left until the 20th. If someone wants to rebuild the release from the 1.3.5 tag and move it out, that would be great. But, sadly, I'm out of the picture for now. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.5 on website?
\On 8/2/06, Paul Benedict <[EMAIL PROTECTED]> wrote: You got me there, Martin :-) It didn't make sense. hehe I do believe the remaining issues can be solved. No time like the present. The 1.3.5 build is tagged, and the repository is open to commits. But that will be a 1.3.6, right? Well, first we'll need a release manager. Any volunteers? If so, set up a plan on the wiki and have at it. We don't have to wait on 1.3.5, a new build could be tagged at any time. It's easy for feature creep to enter into the picture -- so my unclear point (hehe) was that if I deliver some moderate changes, it makes getting a production version out that more complex. I'd like to work on a production branch though before delivering. Some people have had 1.3 "in production" for over a year. In fact, since we "eat our own dog food", we expect committers and other developers to put a milestone in production first, so that we can find problems with edge cases. At this point, 1.3.5 is what it is. If it makes GA, it makes GA. The tag is set, the die is cast. If someone wants to start a new line of development, it's not hard to create a branch in the sandbox, and then merge it back into the trunk later. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts not on JIRA List
On 8/2/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Yup. I know we have our own JIRA instance, but since it's not listed in the directory of >JIRA sites, as Wendy said, you wouldn't know it exists just by browsing that page. This particular page is generated by JIRA, and I'm not aware of a way to change the software-generated listing. If this bothers you, the next best thing would be to cobble up a new "Welcome" message for the top of the page that reminds people that some projects may have their own JIRA instance, and that the best source is the project's website, and submit the patch to the INFRA JIRA project. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles] Test failure in tiles-core
Greg Reddin ha scritto: Yep I'm getting it too. Antonio, did you perhaps forget to check something in? Ok fixed, sorry for any inconvenience. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Free HostedQA account available
Wendy, Your account is set up - I'll follow up with details by email. I don't see the "selenium" profile in the Struts 2 poms - is this a 1.x thing for now? HostedQA doesn't need Selenium Core to be packaged in the webapp. It also can import HTML files used by Selenium Core (and generated by Selenium IDE), but it stores them on the server in its own custom format. If you think it is necessary to store tests in SVN with the code, we should talk and work out the requirements for such a feature and I'll get it in the queue. As for automating Selenium tests in general, Selenium Core isn't well-suited for the type of end-to-end automation you're looking for. However, Selenium Remote Control is and may be able to help. Though, in my very biased opinion, and as the creator of Selenium Remote Control, I'd really recommend just using HostedQA. It is a lot easier to set up (2 ant tasks) and supports a lot more features :) Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29580&messageID=77584#77584 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Ted, Good questions. Related to that - why is it than i18n resource bundles are tied to the action class rather than the _view_ (the view would tend to make more sense, I believe). This is the kind of stuff we should clean up with Struts 2. One thing I'd add before Jason chimes in is that you can tie validation to the action name by naming the file ActionClasss-actionName-validation.xml. But you still also must have the action class in the filename as well. Perhaps the best thing to do to address these little issues is to mock out what an ideal webapp would look like using ideal configurations/annotations. It won't work, of course, but it would be a great blueprint for what we should aim for. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77586#77586 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: Perhaps the best thing to do to address these little issues is to mock out what an ideal webapp would look like using ideal configurations/annotations. I'm trying to do that now with the MailReader application, but I'm running into wildcard issues :( Film at 11. One notion would be the idea of using a combined mapping/validation/message configuration as a "code-behind", and then offering the same utilty via annotations. So, for a given Action class, we might have a single XML, along the lines of /pages/Registration.jsp MainMenu error.username.required User Name is required error.password.required < text>Password is required Which would not necessarily obviate have separate -validation, -action, and -message files, if desired. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
On 8/2/06, Ted Husted <[EMAIL PROTECTED]> wrote: So, for a given Action class, we might have a single XML, along the lines of Which is to say there might be a mailreader2/Register/ * Retrieve.java * Retrieve.xml with the aforementioned elemens. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
I would think an ideal application would have the following: - zero configuration (using conventions instead) for actions and results - overrides possible in struts.xml, including wildcards - result overrides via annotations if struts.xml is too verbose - annotations for validations and type conversion - overrides possible in xml - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77604#77604 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Free HostedQA account available
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: I don't see the "selenium" profile in the Struts 2 poms - is this a 1.x thing for now? Shale, actually. :) But it's the mailreader app, so they should work for 1.x also: http://svn.apache.org/repos/asf/shale/framework/trunk/shale-apps/pom.xml and just a couple of simple tests: http://svn.apache.org/repos/asf/shale/framework/trunk/shale-apps/shale-mailreader/src/test/selenium/ HostedQA doesn't need Selenium Core to be packaged in the webapp. It also can import HTML files used by Selenium Core (and generated by Selenium IDE), but it stores them on the server in its own custom format. If you think it is necessary to store tests in SVN with the code, we should talk and work out the requirements for such a feature and I'll get it in the queue. As for automating Selenium tests in general, Selenium Core isn't well-suited for the type of end-to-end automation you're looking for. However, Selenium Remote Control is and may be able to help. Though, in my very biased opinion, and as the creator of Selenium Remote Control, I'd really recommend just using HostedQA. It is a lot easier to set up (2 ant tasks) and supports a lot more features :) Sorry, I wasn't clear. When I asked how to automate the tests, I meant 'How do I automate the tests with HostedQA?" Locally, all I want is to be able to easily run the tests in a single container/browser combination. This is just a sanity check like running 'mvn clean test' before checking in changes. I've got that by storing the tests in src/test/selenium and enabling the profile to package them with the webapp. So yes, I do want the tests stored in svn. If you have an import facility that converts them to the format you need, that sounds fine. But I'd also like to see the tests you've written for the Struts 2 apps. I'm still at the "Record with Selenium IDE and do minor editing" stage. :) Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: - zero configuration (using conventions instead) for actions and results OK, now define the ideal conventions. :) -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon 2006
I'll be there. How far off are we from rolling another s2 release? -- James Mitchell 678.910.8017 On Jul 28, 2006, at 12:17 PM, Don Brown wrote: My "Struts 2.0" talk was accepted, and I believe James Mitchell has volunteered to join me on stage. Now, if only we had a stable release to brag about... :) Don Ted Husted wrote: ApacheCon US has accepted my offer to present a half-day tutorial on Migrating to Struts 2. Is anyone else presenting about Struts this year? -Ted. - 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: [action2] Free HostedQA account available
To automate tests in HostedQA, just log in and import a test from Selenium IDE or create a new one. It will get run within 30 minutes of a checkin. HostedQA does have an import tool, so you could store the tests in HTML format in SVN. But there isn't an automatic way to import those in (yet). I will see what we can do about that. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29580&messageID=77651#77651 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
> > - zero configuration (using conventions instead) > for actions and results > > OK, now define the ideal conventions. :) Heh - alright. I'll give it a stab. This comes from the conventions I've used in WebWork for two apps (HostedQA and www.bigbark.net). - A single package (or set of packages) that your actions exist in, such as "com.acme.actions" - Classes named FooAction map to the action named "foo" - Paths come from sub-packages inside of com.acme.actions. Ex: com.acme.actions.foo.BarAction -> /foo/bar - Results map to the same directory path with the addition of "-success" and are JSP only. Ex: com.acme.actions.foo.BarAction with a SUCCESS result maps to /foo/bar-success.jsp. - If bar-success.jsp can't be found, try bar.jsp. - Results can be overridden using a @Result annotation at the class or method level, or both. There you can specify basically what you can specify in XML today. I think that's it. Does that make sense? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77653#77653 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon 2006
On 8/2/06, James Mitchell <[EMAIL PROTECTED]> wrote: I'll be there. How far off are we from rolling another s2 release? Closer than October :) Right now, I'm updating the MailReader to lose the aliases and exploit wildcards and namespaces. We should also remove the aliases from Showcase. (WW-1353) WW-768 is a fairly serious issue, since duplicate IDs are not valid XHTML. Under WW-1340, quite a few of the snippets seem to be broken. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Classes named FooAction map to the action named "foo"
Paths come from sub-packages inside of com.acme.actions. Ex:
com.acme.actions.foo.BarAction -> /foo/bar
If we conform the case, and drop the "Action" suffix, this turns into
a very clean wildcard expression:
*
So the action reference for "whatever.foo.Bar" would be "/foo/Bar"
Results map to the same directory path with the addition of "-success"
If we use the packages for folder names, and the class names for page
names, then we could use another clean wilcard expression.
* /{1}/{2}.jsp
So, the nominal result for the foo.Bar action would be /foo/Bar.jsp.
We could consider providing some wildcard defaults in the default
package, which people could then tweak and override as needed.
-T.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.5 on website?
On 8/2/06, Ted Husted <[EMAIL PROTECTED]> wrote: That's true, but looking over my schedule, I have no discretionary time left until the 20th. If someone wants to rebuild the release from the 1.3.5 tag and move it out, that would be great. I'll try to do it Thursday night, but most likely it will be some time this weekend. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Patrick and I talked about doing that, however, we came up against several
roadblocks:
1. How would you handle nested packages? For example: /foo/bar/joe?
2. How would you handle action methods?
3. The case might not always match
One possible solution would be to introduce "wildcard modifiers" that would let
you modify the wildcard-matched value. For example, in problem #3, you would
want to have "foo/bar" used for the action class "com.acme.{1}.{2}". You could
apply a modifier like so - "com.acme.{1}.{2|capitalize}" - which would
capitalize the Action name. The idea from these modifiers comes from Javascript
Templates [1].
The modifiers could solve problems 3 and maybe 1
("com.acme.{1|slashesToDots}.{2|capitalize}"), and perhaps #2 could be solved by
using the "!" separator instead of the "/" again.
However, the question must be raised whether these improvements obscure the
somewhat advanced wildcard capability. There is a danger in being too fancy for
your own good, resulting in a feature that is perceived as too complicated and
detrimental to the framework. Whether that applies here is up for discussion.
Don
Ted Husted wrote:
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Classes named FooAction map to the action named "foo"
Paths come from sub-packages inside of com.acme.actions. Ex:
com.acme.actions.foo.BarAction -> /foo/bar
If we conform the case, and drop the "Action" suffix, this turns into
a very clean wildcard expression:
*
So the action reference for "whatever.foo.Bar" would be "/foo/Bar"
Results map to the same directory path with the addition of "-success"
If we use the packages for folder names, and the class names for page
names, then we could use another clean wilcard expression.
* /{1}/{2}.jsp
So, the nominal result for the foo.Bar action would be /foo/Bar.jsp.
We could consider providing some wildcard defaults in the default
package, which people could then tweak and override as needed.
-T.
-
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: [s2] Validation
On 8/2/06, Don Brown <[EMAIL PROTECTED]> wrote:
Patrick and I talked about doing that, however, we came up against several
roadblocks:
1. How would you handle nested packages? For example: /foo/bar/joe?
Do we need to handle nested packages?
2. How would you handle action methods?
In the scope of convention over configuraion, I'd suggest that we
don't utilize multiple action methods. I'm coming to the conclusion
that multiple aliases on an action is not a good practice, much like
chaining actions is not a good practice.
If we adopt the perspective that one-method per action is the
cannonical norm, then everything falls into place. The key trouble
with one-method per action is it increases the number of similar
action mappings to maintain. But between wildcards, an extends
feature, and annotations, that problem goes away.
3. The case might not always match
Hmmm, I thought the whole idea behind convention over configruation is
that we *make* these things match because they are *suppose* to match.
One possible solution would be to introduce "wildcard modifiers" that would let
you modify the wildcard-matched value. For example, in problem #3, you would
want to have "foo/bar" used for the action class "com.acme.{1}.{2}". You could
apply a modifier like so - "com.acme.{1}.{2|capitalize}" - which would
capitalize the Action name. The idea from these modifiers comes from Javascript
Templates [1].
The modifiers could solve problems 3 and maybe 1
("com.acme.{1|slashesToDots}.{2|capitalize}"), and perhaps #2 could be solved by
using the "!" separator instead of the "/" again.
However, the question must be raised whether these improvements obscure the
somewhat advanced wildcard capability. There is a danger in being too fancy for
your own good, resulting in a feature that is perceived as too complicated and
detrimental to the framework. Whether that applies here is up for discussion.
I'd agree that supporting all fancy alternatives is not a good idea.
The goal should be to solve use cases, not cater to every whim about
what should be upper or lower case.
People who want to fine-tune this sort of thing can use configuration
over convention. Convention over configuration should be for people
who are actually willing to follow a convention.
And, if we use wildcards to define a default convention, there would
be nothing preventing someone from defining another wildcard
convention, suitable to specific needs.
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
