Re: Resolving/Closing JIRA issues
I don't know if it makes any practical difference, but I wonder if we should decide to use either "Resolved" or "Closed", but not both. Right now, we seem to be using either/or, willy-nilly. Following up on Don's observations, my preferences would be to keep it simple and just use Resolved and forget about Closed. (Or vice-versa, since we can edit Closed tickets too.) -Ted. On Aug 9, 2007 12:32 AM, Don Brown <[EMAIL PROTECTED]> wrote: > I believe the traditional purpose of the "closed" state is for a QA > department, so they can mark the issues they have verified to be > fixed. In Struts, I don't think we really do that, and while we do > informal code reviews (commit emails), we certainly don't require > formal test documents that verify the ticket resolution is correct. > If a release manager wants to take that role upon themselves, that's > great, but it should be purely optional. > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get web application file path from java stand alone program?
Hi all,
I am using Jboss server with struts.I used java class for getting the
real path
of web application.This class iscalled by my Sheduler class that is run
automatically when application server start and not called by Action class.
How I get web application path from my java class?
Here is my code
class MyJavaClss
{
static getPath()
{
String path=""; // How I get the path of "... //webroot//report/report.xml"
}
}
In Action class I can do with
getServlet().getServletContext().geRealPath("\\report\\JReports\\summary\\");
It gives currect path like
C:\jboss-4.0.1sp1\server\default\deploy\united.war\report\JReports\summary
But how I get this path from my Java Class (not struts Action class)
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=151372&messageID=224111#224111
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Patch a Day Challenge
Just to follow up, already this week, we've resolved 25 issues, including 13 that were tagged for 2.1.1. We have another 47 in the 2.1 series, which, at this rate, we could have knocked off by ApacheCon. If you consider yourself an active Struts 2.x committer, and you haven't resolved a JIRA issue this week, please try to carve out a little time to resolve at least one issue this month. Technically, we've come a long way with 2.x, and this would be an excellent time to make sure that is also issue-free. -Ted. On Oct 29, 2007 3:10 PM, Ted Husted <[EMAIL PROTECTED]> wrote: > I marked all the unresolved tickets marked "patch" for the 2.1.1 > version. Altogether, there are less than sixty. I'd like to encourage > all the committers to make an effort to resolve one or more of these > tickets over the next sixty days. If between us we can at least knock > off one a day, we can have them all resolved by the end of December. > (Of course, sooner would be even better!) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get web application file path from java stand alone program?
Please ask questions like this on the struts-user
mailing list, struts-dev is for the development of
struts itself.
Thanks,
Dave
--- Sathesh Kumar <[EMAIL PROTECTED]>
wrote:
> Hi all,
> I am using Jboss server with struts.I used
> java class for getting the real path
> of web application.This class iscalled by my
> Sheduler class that is run automatically when
> application server start and not called by Action
> class.
> How I get web application path from my java
> class?
>
> Here is my code
>
> class MyJavaClss
> {
>
> static getPath()
> {
> String path=""; // How I get the path of "...
> //webroot//report/report.xml"
> }
>
> }
>
> In Action class I can do with
>
>
getServlet().getServletContext().geRealPath("\\report\\JReports\\summary\\");
>
> It gives currect path like
>
>
C:\jboss-4.0.1sp1\server\default\deploy\united.war\report\JReports\summary
>
> But how I get this path from my Java Class (not
> struts Action class)
>
-
> Posted via Jive Forums
>
http://forums.opensymphony.com/thread.jspa?threadID=151372&messageID=224111#224111
>
>
>
-
> 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Just to followup, I setup a Google Code site as a place to describe and design cross-platform technologies that pertain to web application development and deployment. For some time now, I've spent half my time working in .NET, which probably won't change for another year or two, and so working on cross-platform technologies is of great interest to me. I've extended the initial draft posted here to include the action URI to Action Class mappings. While based on SmartURLs and CodeBehind, the description goes beyond what either can do right now. * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001 Before doing any more work on the description, I'd be very interested on feedback as to whether I'm making any sense, or whether the draft has turned into opaque gibberish :) -Ted. On Oct 17, 2007 2:24 AM, Ted Husted <[EMAIL PROTECTED]> wrote: > Following up on suggestions made by Don and Brian, I'd like to propose > that we draft a formal specification describing the logic to be used > by the (deep-breath) "Able/Code Behind/Zero-Config/SmartURLs" plugin > for 2.1. The purpose of the specification would be to better define > what "backward compatibility" means, and also to encourage > implementation of this pattern by other frameworks. > > Following is the beginning of an early draft of a proposed > "view-behind" specification. (In case anyone is interested, I'm using > the JSON-RPC specification format as a model.) If there is interest in > this proposal, I'd suggest we decide whether to complete the > specification as part of our documentation, or at some other location. > Of course, people working with other frameworks > (stripes) would be welcome to join in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Looks good to me. I was going to suggest putting this on the wiki, but a googlecode project is even better. So would the code for this new struts2 plugin live here or in the struts codebase? On 11/1/07, Ted Husted <[EMAIL PROTECTED]> wrote: > Just to followup, I setup a Google Code site as a place to describe > and design cross-platform technologies that pertain to web application > development and deployment. For some time now, I've spent half my time > working in .NET, which probably won't change for another year or two, > and so working on cross-platform technologies is of great interest to > me. > > I've extended the initial draft posted here to include the action URI > to Action Class mappings. While based on SmartURLs and CodeBehind, the > description goes beyond what either can do right now. > > * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001 > > Before doing any more work on the description, I'd be very interested > on feedback as to whether I'm making any sense, or whether the draft > has turned into opaque gibberish :) > > -Ted. > > > On Oct 17, 2007 2:24 AM, Ted Husted <[EMAIL PROTECTED]> wrote: > > Following up on suggestions made by Don and Brian, I'd like to propose > > that we draft a formal specification describing the logic to be used > > by the (deep-breath) "Able/Code Behind/Zero-Config/SmartURLs" plugin > > for 2.1. The purpose of the specification would be to better define > > what "backward compatibility" means, and also to encourage > > implementation of this pattern by other frameworks. > > > > Following is the beginning of an early draft of a proposed > > "view-behind" specification. (In case anyone is interested, I'm using > > the JSON-RPC specification format as a model.) If there is interest in > > this proposal, I'd suggest we decide whether to complete the > > specification as part of our documentation, or at some other location. > > Of course, people working with other frameworks > > (stripes) would be welcome to join in. > > - > 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
The notion is that Struts and other projects could build their own implementations based on the specification, the same way different groups build components based on the JSON-RPC specification. So, no, we wouldn't put our own implementation on the Google Code site. -Ted. On Nov 1, 2007 9:59 AM, Tom Schneider <[EMAIL PROTECTED]> wrote: > Looks good to me. I was going to suggest putting this on the wiki, > but a googlecode project is even better. So would the code for this > new struts2 plugin live here or in the struts codebase? > > > On 11/1/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > Just to followup, I setup a Google Code site as a place to describe > > and design cross-platform technologies that pertain to web application > > development and deployment. For some time now, I've spent half my time > > working in .NET, which probably won't change for another year or two, > > and so working on cross-platform technologies is of great interest to > > me. > > > > I've extended the initial draft posted here to include the action URI > > to Action Class mappings. While based on SmartURLs and CodeBehind, the > > description goes beyond what either can do right now. > > > > * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001 > > > > Before doing any more work on the description, I'd be very interested > > on feedback as to whether I'm making any sense, or whether the draft > > has turned into opaque gibberish :) > > > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
First, just wanted to cover the plan quick. I was planning on merging the SmartURLs code into the existing codebehind plugin tomorrow and ensuring everything is correctly in the new packages and that the old annotations are correctly deprecated. Is this still how we want to move forward? Second, some thoughts on the specification: Section 5 was somewhat confusing. I had difficulty determining the meanings of terms used in section 5 during my first read. Some of them were later defined in the examples in section 5.1. Particularly code-suffix, was defined and then not used again until the examples. It was replaced with 'Code Component Suffix', which isn't in the definitions section. However, 'Code Suffix' was defined. I would start off with detailed descriptions of the three strategies for action matching in section 5. These descriptions should use the definitions in section 4. The examples are somewhat confusing because there isn't any definition about non-code-suffixed actions, which in the Struts case are determined via implementation of the Action interface. This should probably be spelled out is some type of action-type matching. #2 , #4 and #5 fall into this category. Also, #5 needs an code-suffix variant. And #6 needs an action-type variant. I would think that a scanning methodology would be best rather than just a fall back. Something like /my/namespace/action /my/action /action Also, transform-code-prefix and transform-code-name aren't defined anywhere and the only workflow that is spelled out is the Mapping Name transformation. It seems like there is a change between capitalized definitions and their dash/lowercase versions, and sometimes they aren't consistent. I would define everything once using the dash version and ensure that all capital usages are replace accordingly. This will make it simpler to reference through out. You could also go with the capital versions and replace the dash versions. Either way should work, but the dash versions look better in the BNF. Also, using the code blocks that Google Code provides colorizes strangely. It would probably be better to outline workflows as numbered lists. The BNF looks good in the code blocks but some are colorized and some aren't. This makes it difficult to pull out the BNF when scanning. I'd also put in some mention that the heuristic can be handled on demand or pre-loaded. The way that the current workflows are presented it sounds like the code and results are only found on demand and not pre-configured to speed things up. -bp Ted Husted wrote: Just to followup, I setup a Google Code site as a place to describe and design cross-platform technologies that pertain to web application development and deployment. For some time now, I've spent half my time working in .NET, which probably won't change for another year or two, and so working on cross-platform technologies is of great interest to me. I've extended the initial draft posted here to include the action URI to Action Class mappings. While based on SmartURLs and CodeBehind, the description goes beyond what either can do right now. * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001 Before doing any more work on the description, I'd be very interested on feedback as to whether I'm making any sense, or whether the draft has turned into opaque gibberish :) -Ted. On Oct 17, 2007 2:24 AM, Ted Husted <[EMAIL PROTECTED]> wrote: Following up on suggestions made by Don and Brian, I'd like to propose that we draft a formal specification describing the logic to be used by the (deep-breath) "Able/Code Behind/Zero-Config/SmartURLs" plugin for 2.1. The purpose of the specification would be to better define what "backward compatibility" means, and also to encourage implementation of this pattern by other frameworks. Following is the beginning of an early draft of a proposed "view-behind" specification. (In case anyone is interested, I'm using the JSON-RPC specification format as a model.) If there is interest in this proposal, I'd suggest we decide whether to complete the specification as part of our documentation, or at some other location. Of course, people working with other frameworks (stripes) would be welcome to join in. - 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]
Messing around with parameters
So, just wanted to toss this into the mix and see what you all thought. Here's the issue I had: Vertigo has a Money object that is a value and currency. I wanted to set the value from a form. I wanted the currency code to be definable for that specific form element. Oh, and Money is immutable. I wrote up a simple TypeConverter to convert to the Money object. Only problem was getting the currency code. After trying a few different things, I decided to sub-class the parameters interceptor and add a concept that I call parameter attributes. These get added to the ValueStack context and then are accessible to the converter. They look like this: For each HTTP parameter, I assume that if the parameter contains an at-sign (@) it is an attribute of another parameter. This gets placed into a Map of attributes. Once all the attributes are found for each parameter, I iterate over the parameters and then add all of that parameters the attributes to the ValueStack context Map. I picked the at-sign because it looks like an 'a', which makes it easy to remember it is an attribute and isn't a valid Java identifier character. This does conflict with OGNL class and member accessors, but we shouldn't be evaluating the parameter names in that manner, so it should be fine. I've found that this is really useful for loads of different situations including free form date input fields where you need to convert to a Date and then back to a String and want the format to be preserved. I use Joda rather than the JDK (go Joda!) and this works really nicely for that case. Looks like: Essentially, this is really helpful for immutable types that have multiple values such as phone numbers and money and types that have tricky parsing semantics like dates. I think this would be a good addition to core, but I wanted to toss it out there first. Thoughts? -bp p.s. Oh and if someone knows of a standard way to do this that I missed, let me know! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
On 11/2/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > First, just wanted to cover the plan quick. I was planning on merging > the SmartURLs code into the existing codebehind plugin tomorrow and > ensuring everything is correctly in the new packages and that the old > annotations are correctly deprecated. Is this still how we want to move > forward? I think this is a great case where we need a tech spec before merging the code. The spec should cover the problem, use cases, proposed solution, and implementation details. The document ted put together is a good start for the general approach, but this spec would be more focused on exactly how the codebehind plugin would change and why. We all have different ideas how the codebehind plugin will work and why, and a tech spec will help focus this discussion, and serve as useful documentation later. Don Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Don Brown wrote: On 11/2/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: First, just wanted to cover the plan quick. I was planning on merging the SmartURLs code into the existing codebehind plugin tomorrow and ensuring everything is correctly in the new packages and that the old annotations are correctly deprecated. Is this still how we want to move forward? I think this is a great case where we need a tech spec before merging the code. The spec should cover the problem, use cases, proposed solution, and implementation details. The document ted put together is a good start for the general approach, but this spec would be more focused on exactly how the codebehind plugin would change and why. I can start working on the specifics with respect to the current functionality in SmartURLs and the proposals that are on the table and gear it specifically at the new plugin. We all have different ideas how the codebehind plugin will work and why, and a tech spec will help focus this discussion, and serve as useful documentation later. I think we might have slightly different ideas, but in general I imagine everyone is pretty much inline and flexible enough to accept ideas from others. I'll bang out the spec today and tomorrow and then see where we are at. I'll put that in a wiki page over at the SmartURLs and build on the abstraction that Ted started. Don -bp Don -bp ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
On 11/2/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > I think we might have slightly different ideas, but in general I imagine > everyone is pretty much inline and flexible enough to accept ideas from > others. I'll bang out the spec today and tomorrow and then see where we > are at. I'll put that in a wiki page over at the SmartURLs and build on > the abstraction that Ted started. That's the trick of writing against an evolving interface spec - your implementation is never done until the spec is finished. In this case, it is a spec against a spec :) Here is the problem I've having - we are writing a book, and since this whole issue seems far from resolution, we've been using the XML configuration throughout the book (it is almost done). What I'd rather have done is use the convention stuff to cut the code size and complexity of the examples down, which, IMO, would have made it easier to learn. Therefore, I'd like to get this resolved asap. I'll try to find some time to review Ted's proposal, but if he is aiming to get other frameworks involved, it might be a while till it is done. In the meantime, do you feel SmartURLs is exactly what you'd want the new plugin (or updated codebehind plugin) to look like, or are there features you would change/cut? If you want it the way it is, we can use its docs as the spec and start the discussion there. Having used SmartURLs for a while now, having read Ted's spec, having spend some time thinking about the topic, I'd be curious to see how you think it should be done, as if starting from scratch. Don > > > Don > > > -bp > > Don > > > -bp ;) > > > - > 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: Messing around with parameters
I've always wondered why all parameters are not passed to the converter. There are a lot of cases, (like yours) when the conversion depends on other parameters. If all parameters were passed to the converter you wouldn't need this right? I feel kind of uncomfortable with adding yet another syntax. musachy On 11/1/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > So, just wanted to toss this into the mix and see what you all thought. > Here's the issue I had: > > Vertigo has a Money object that is a value and currency. I wanted to set > the value from a form. I wanted the currency code to be definable for > that specific form element. Oh, and Money is immutable. > > I wrote up a simple TypeConverter to convert to the Money object. Only > problem was getting the currency code. After trying a few different > things, I decided to sub-class the parameters interceptor and add a > concept that I call parameter attributes. These get added to the > ValueStack context and then are accessible to the converter. They look > like this: > > > > > For each HTTP parameter, I assume that if the parameter contains an > at-sign (@) it is an attribute of another parameter. This gets placed > into a Map of attributes. Once all the attributes are found for each > parameter, I iterate over the parameters and then add all of that > parameters the attributes to the ValueStack context Map. > > I picked the at-sign because it looks like an 'a', which makes it easy > to remember it is an attribute and isn't a valid Java identifier > character. This does conflict with OGNL class and member accessors, but > we shouldn't be evaluating the parameter names in that manner, so it > should be fine. > > I've found that this is really useful for loads of different situations > including free form date input fields where you need to convert to a > Date and then back to a String and want the format to be preserved. I > use Joda rather than the JDK (go Joda!) and this works really nicely for > that case. Looks like: > > > > > Essentially, this is really helpful for immutable types that have > multiple values such as phone numbers and money and types that have > tricky parsing semantics like dates. I think this would be a good > addition to core, but I wanted to toss it out there first. > > Thoughts? > > -bp > > p.s. Oh and if someone knows of a standard way to do this that I missed, > let me know! > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Don Brown wrote: On 11/2/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: I think we might have slightly different ideas, but in general I imagine everyone is pretty much inline and flexible enough to accept ideas from others. I'll bang out the spec today and tomorrow and then see where we are at. I'll put that in a wiki page over at the SmartURLs and build on the abstraction that Ted started. That's the trick of writing against an evolving interface spec - your implementation is never done until the spec is finished. In this case, it is a spec against a spec :) Yeah, tricky. hehe Here is the problem I've having - we are writing a book, and since this whole issue seems far from resolution, we've been using the XML configuration throughout the book (it is almost done). What I'd rather have done is use the convention stuff to cut the code size and complexity of the examples down, which, IMO, would have made it easier to learn. Therefore, I'd like to get this resolved asap. Okay, let's do it. I should be able to have a good grasp on the exact requirements and proposals for the new plugin tomorrow morning. Here's what I've started: http://code.google.com/p/smarturls-s2/wiki/TechnicalSpecification I'll try to find some time to review Ted's proposal, but if he is aiming to get other frameworks involved, it might be a while till it is done. In the meantime, do you feel SmartURLs is exactly what you'd want the new plugin (or updated codebehind plugin) to look like, or are there features you would change/cut? If you want it the way it is, we can use its docs as the spec and start the discussion there. Having used SmartURLs for a while now, having read Ted's spec, having spend some time thinking about the topic, I'd be curious to see how you think it should be done, as if starting from scratch. I think there are two changes I'm going to make: 1. Remove smarturls.action.packages and replace this with smarturls.action.package.identifiers, which is the list of identifiers that package names must contain. This would default to "action,actions,struts,struts2". This would require two annotations and two properties to turn specific packages on and off. 2. Remove the component.xml file handling for components and rely on the changes in #1 to find actions and result locations for components. This would make it simpler to start working and create java-packages that contain actions. Plus, it would support all the component infrastructure that I need in a completely standard fashion. Besides that, I feel that everything else is fine and all we would be adding would be features. Nothing else really needs to be completely changed, but these two changes would impact applications that are already built on SmartURLs and codebehind. So, if I bang out this specification, which would include the existing functionality with the changes above and a few other things I want to add in terms of features (i.e. searching / interceptors / defaults / exceptions / etc), would you feel comfortable writing the book against that? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Messing around with parameters
True to some degree. You still have the issue that some of the parameters don't map to properties of the JavaBean. If you did this: You would need to specify that the currencyCode should be excluded, which means more configuration (especially if Raible gets all the changes in for his exception throwing for bad parameters, which I'm definitely behind). I like the concept of attributes a lot because they indicate values that are naturally excluded and that only have meaning to another parameter. I can understand the sentiment about another syntax, but adding good examples and information to the documentation for type conversion would clear that up a lot. Plus, this syntax really only applies to type conversion (at least that I can think of), which means that it is centralized and can be documented as such. -bp Musachy Barroso wrote: I've always wondered why all parameters are not passed to the converter. There are a lot of cases, (like yours) when the conversion depends on other parameters. If all parameters were passed to the converter you wouldn't need this right? I feel kind of uncomfortable with adding yet another syntax. musachy On 11/1/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: So, just wanted to toss this into the mix and see what you all thought. Here's the issue I had: Vertigo has a Money object that is a value and currency. I wanted to set the value from a form. I wanted the currency code to be definable for that specific form element. Oh, and Money is immutable. I wrote up a simple TypeConverter to convert to the Money object. Only problem was getting the currency code. After trying a few different things, I decided to sub-class the parameters interceptor and add a concept that I call parameter attributes. These get added to the ValueStack context and then are accessible to the converter. They look like this: For each HTTP parameter, I assume that if the parameter contains an at-sign (@) it is an attribute of another parameter. This gets placed into a Map of attributes. Once all the attributes are found for each parameter, I iterate over the parameters and then add all of that parameters the attributes to the ValueStack context Map. I picked the at-sign because it looks like an 'a', which makes it easy to remember it is an attribute and isn't a valid Java identifier character. This does conflict with OGNL class and member accessors, but we shouldn't be evaluating the parameter names in that manner, so it should be fine. I've found that this is really useful for loads of different situations including free form date input fields where you need to convert to a Date and then back to a String and want the format to be preserved. I use Joda rather than the JDK (go Joda!) and this works really nicely for that case. Looks like: Essentially, this is really helpful for immutable types that have multiple values such as phone numbers and money and types that have tricky parsing semantics like dates. I think this would be a good addition to core, but I wanted to toss it out there first. Thoughts? -bp p.s. Oh and if someone knows of a standard way to do this that I missed, let me know! - 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: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Brian Pontarelli wrote: Besides that, I feel that everything else is fine and all we would be adding would be features. Nothing else really needs to be completely changed, but these two changes would impact applications that are already built on SmartURLs and codebehind. So, if I bang out this specification, which would include the existing functionality with the changes above and a few other things I want to add in terms of features (i.e. searching / interceptors / defaults / exceptions / etc), would you feel comfortable writing the book against that? While on the topic, with respect to defaults/exceptions etc, can I ask the specification addresses how invalid URLs are handled. In the current implementation (0.18) invalid URL's return (unexpected?) success results. ie. http:///www.example.com/invalid/path/to/resource currently maps to the IndexAction at / (incorrectly?) Namespace precedence also seems to be an issue when handling invalid paths and needs to be specified: ie. Assuming pets.IndexAction exists: http://www.example.com/petsmaps to pets.IndexAction (as expected); but the URL: http://www.example.com/pets/dogs maps to /IndexAction if pets.dogs.IndexAction does not exist rather than pets.IndexAction or an exception (which is expected?) My point is, it's currently ambiguous how these exceptions should be handled. Between these and the issues already in the issuelist, my experience with SmartURLs 0.18 hasn't yet been positive except in the simplest of use-cases. I do feel the approach is great and needed though and I'm looking forward to the enhancements. regards, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
On Nov 1, 2007 5:02 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > So, if I bang out this specification, which would include the existing > functionality with the changes above and a few other things I want to > add in terms of features (i.e. searching / interceptors / defaults / > exceptions / etc), would you feel comfortable writing the book against that? Personally, I'd like to see three different applications written entirely with the conventions, before I'd be comfortable calling anything like this stable. Good examples might be the MailReader, the ShowCase, and a Struts Petstore. The point of the exercise is to make it easier to write applications. The one and only way for anyone to know if this stuff actually works is to eat our own dog food, and put it to work. Not just on what we are doing in-house, but on public examples, that we ourselves did not contrive, and that other people can review and dissect. Looking at the latest SmartURLs MailReader (r119), * http://people.apache.org/~husted/mail-reader-0.19-SNAPSHOT.war the biggest pain-point is redirects, and nothing we've done so far is addressing that concern. I'm sure we won't be able to solve the problem of when and where to redirect 100% of the time, but if we can use conventions even 80% of the time, we're starting to save actual effort. The common use case for redirecting is to redirect after a (successful) POST, mostly because we don't want them to resubmit again, and also because it usually signals the end of a workflow, and implies it's time to return to a menu or some other parent workflow. The POST part we could trap one way or another. The hinky part is where the redirect should go (at least by default). Now, as Brian mentioned, something else we haven't been doing is considering the namespaces an actual heirarchy. In both Struts 1 and Struts 2, the slashes are just characters, and the namespace is just a string. But, what if we adopting the convention of nesting namespaces to represent parent/child hierarchies. For example, in the MailReader, that would mean that instead of "register" and "subscribe" namespaces, we should have "register" and "register/subscribe", or even "/menu/register/subscribe". If we consider namespaces a hierarchy, and we adopt the convention of honoring Index pages, then a likely default behavior after a successful POST might be to redirect to "../Index", or to the first "higher" Index we find. Again, "redirecting up after post" won't eliminate the need to annotate redirects, but it may decimate the need. Of course, there are other pain-points in the MailReader, and I'm sure we'd find others in new implementations of the ShowCase and Petstore. But, the point of the plugin and the spec should be to identify what actually helps us write various applications ... and trying to lower our tolerance to pain :) Overall, my own preference would be to first finish what we've started with the SmartURLs plugin for Struts 2.0.x. When we can use it to write the simplest possible MailReader, ShowCase, and Petstore, then let's make bring it onboard as the new CodeBehind for Struts 2.1.x. If there's something that the CodeBehind does that SmartURLs doesn't do, then let's port that functionality over. As to the generic specification, for the last two years, I've spent half my time working in .NET, and it looks like that will be the status quo for at least a couple of years more. I'm really liking the heuristic mappings strategy, and, regardless of what else is happening, I'll be implementing a .NET version that we can use at work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
On Nov 1, 2007 6:34 PM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > While on the topic, with respect to defaults/exceptions etc, can I ask > the specification addresses how invalid URLs are handled. The specification implies that the implementation should raise a 404. > In the > current implementation (0.18) invalid URL's return (unexpected?) success > results. > > ie. http:///www.example.com/invalid/path/to/resource currently maps to > the IndexAction at / (incorrectly?) > > Namespace precedence also seems to be an issue when handling invalid > paths and needs to be specified: > > ie. > Assuming pets.IndexAction exists: > http://www.example.com/petsmaps to pets.IndexAction (as expected); > but the URL: > http://www.example.com/pets/dogs maps to /IndexAction if > pets.dogs.IndexAction does not exist rather than pets.IndexAction or an > exception (which is expected?) So far, treating the namespaces as a hierarchy has not been the expected behavior. Struts 2 checks the current namespace for a result, and then the default (empty) namespace. So the behavior you describe is consistent with the rest of Struts 2. Although, as mentioned elsewhere, viewing the namespaces as a hierarchy may be more useful. > My point is, it's currently ambiguous how these exceptions should be > handled. Between these and the issues already in the issuelist, my > experience with SmartURLs 0.18 hasn't yet been positive except in the > simplest of use-cases. I do feel the approach is great and needed > though and I'm looking forward to the enhancements. Could you be more specific as to what enhancements would be the most useful? I find that making the best use of SmartURLs does mean taking a fresh look at the application, and sometimes refactoring the layout, much the same way we sometimes refactor a database schema to work better with ORM systems, like Hibernate or JPA. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification]
Ted Husted wrote:
Could you be more specific as to what enhancements would be the most useful?
My smarturl's wishlist:
- perform hierarchical namespace scanning as proposed by Ted
- allow namespace wildcards as per the new REST plugin:
@Namespace("/pets/{type}");
- accept URL path params as per smarturls-s2 Issue 5
At this point, I'd also like it to become abundantly clear how the
namespace/action/method mapping implemented used by SmartURLs and the
REST plugin differ and make them consistent where sensible to do so,
particularly regarding namespace hierarchy/scanning. Eventually a
side-by-side mapping comparison will be useful for developers. I'd
encourage SmartURLs to become the defacto mapping implementation for
Struts2 and REST the pluggable alternative.
- handling of 404s, which is a different problem entirely after
implementing the 3 points above
- add compatibility with xwork 2.1.x (the 0.18 release can't execute
against Struts2.1)
- remove the savant build dependency/augment it with maven2
- I do like the idea of a default redirect convention but haven't
thought it through. Any convention is better than none.
I'm not sure any of that opinion helps right now. I'm not using
SmartURLs in any for-production code at the moment as 0.18 didn't "pass"
my evaluations. I am using the REST plugin however primarily because I
preferred its URL mapping.
regards,
Jeromy Evans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Ted Husted wrote: On Nov 1, 2007 5:02 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: So, if I bang out this specification, which would include the existing functionality with the changes above and a few other things I want to add in terms of features (i.e. searching / interceptors / defaults / exceptions / etc), would you feel comfortable writing the book against that? Personally, I'd like to see three different applications written entirely with the conventions, before I'd be comfortable calling anything like this stable. Good examples might be the MailReader, the ShowCase, and a Struts Petstore. I have written ~10 applications to date using it: http://www.inversoft.com (to be launched with Vertigo in the next few weeks) http://www.mocapay.com http://www.ireland-stapleton.com (to be launched next week) http://www.pentaxian.com http://www.texturemedia.com and a few other public applications that I can't recall off the top of my head and 3 or so internal applications. I've also built 3 components using it, a CMS component, News component and User component. All of these components are being used in the above sites. The point of the exercise is to make it easier to write applications. The one and only way for anyone to know if this stuff actually works is to eat our own dog food, and put it to work. Not just on what we are doing in-house, but on public examples, that we ourselves did not contrive, and that other people can review and dissect. I think my point is that although it has some downsides, it is live in production sites and is working. It obviously can use improvements, but I tend to feel that it works and makes things simpler than using XML. I don't see gaping holes that need to be addressed and from my perspective, anything we might add would be niceties and enhancements, not fundamental changes of direction. Looking at the latest SmartURLs MailReader (r119), * http://people.apache.org/~husted/mail-reader-0.19-SNAPSHOT.war the biggest pain-point is redirects, and nothing we've done so far is addressing that concern. Agreed. This one could use some thought, but there is currently a solution that is still less headache than XML. Once we have a better solution it will simply make things even easier. I'm sure we won't be able to solve the problem of when and where to redirect 100% of the time, but if we can use conventions even 80% of the time, we're starting to save actual effort. Perhaps, but this might be understating the number of possibilities. The common use case for redirecting is to redirect after a (successful) POST, mostly because we don't want them to resubmit again, and also because it usually signals the end of a workflow, and implies it's time to return to a menu or some other parent workflow. The POST part we could trap one way or another. The hinky part is where the redirect should go (at least by default). Yeah, that's the trick. I need to think on it, but I'm sure we could come up with something. Now, as Brian mentioned, something else we haven't been doing is considering the namespaces an actual heirarchy. In both Struts 1 and Struts 2, the slashes are just characters, and the namespace is just a string. But, what if we adopting the convention of nesting namespaces to represent parent/child hierarchies. For example, in the MailReader, that would mean that instead of "register" and "subscribe" namespaces, we should have "register" and "register/subscribe", or even "/menu/register/subscribe". If we consider namespaces a hierarchy, and we adopt the convention of honoring Index pages, then a likely default behavior after a successful POST might be to redirect to "../Index", or to the first "higher" Index we find. Again, "redirecting up after post" won't eliminate the need to annotate redirects, but it may decimate the need. Could work, but I have a feeling there might be something even better. Just need to have it pop into someone's head at some point. Of course, there are other pain-points in the MailReader, and I'm sure we'd find others in new implementations of the ShowCase and Petstore. But, the point of the plugin and the spec should be to identify what actually helps us write various applications ... and trying to lower our tolerance to pain :) I'm not sure I think that it is as much pain as you. I see XML as like a 10 and what we have currently as like a 3. I've gotten used to thinking in actions and results. I've gotten away from things like using the action-input urls and worked on more rails like standards. I've tried to ignore result codes whenever possible and use action names for results. Things like that. I find that my pain points are less SmartURLs, but more tricky HTTP/web situations that arise no matter what you are using. Overall, my own preference would be to first finish what we've started with the SmartURLs plugin for Struts 2.0.x. When we can use it to write the simplest possible M
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Jeromy Evans wrote: Brian Pontarelli wrote: Besides that, I feel that everything else is fine and all we would be adding would be features. Nothing else really needs to be completely changed, but these two changes would impact applications that are already built on SmartURLs and codebehind. So, if I bang out this specification, which would include the existing functionality with the changes above and a few other things I want to add in terms of features (i.e. searching / interceptors / defaults / exceptions / etc), would you feel comfortable writing the book against that? While on the topic, with respect to defaults/exceptions etc, can I ask the specification addresses how invalid URLs are handled. In the current implementation (0.18) invalid URL's return (unexpected?) success results. They shouldn't unless it finds a result that will handle the URL. If it can't find one it will throw the standard exception, which should be processed as it currently is. I've tested default actions/results as well as exception and 404/500 handling and it all works fine. If you could give an example that is not working for you, I can look into it. ie. http:///www.example.com/invalid/path/to/resource currently maps to the IndexAction at / (incorrectly?) Yeah, that shouldn't happen because it doesn't currently look up the hierarchy of packages. Not sure why this is happening, but it definitely seems strange. Here's a not so great handling of missing actions: http://www.texturemedia.com/invalid/index.action It is a 500, which is due to the exception thrown from the ActionProxy. Namespace precedence also seems to be an issue when handling invalid paths and needs to be specified: ie. Assuming pets.IndexAction exists: http://www.example.com/petsmaps to pets.IndexAction (as expected); but the URL: http://www.example.com/pets/dogs maps to /IndexAction if pets.dogs.IndexAction does not exist rather than pets.IndexAction or an exception (which is expected?) This is a bit confusing. So, /pets should redirect /pets/ and that should render the /pets/index action. However, /pets/dogs should error out unless there is an action named dogs in /pets or an index action in /pets/dogs. If that isn't working it seems like a bug. My point is, it's currently ambiguous how these exceptions should be handled. Between these and the issues already in the issuelist, my experience with SmartURLs 0.18 hasn't yet been positive except in the simplest of use-cases. I do feel the approach is great and needed though and I'm looking forward to the enhancements. I'm somewhat surprised, but definitely willing to fix this stuff if we can reproduce it. All of the cases you have mentioned work fine in all of the applications I've built to date so any code examples would be helpful. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
On 11/1/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > I've also built 3 components using it, a CMS component, News component > and User component. All of these components are being used in the above > sites. > If you don't mind my asking, what CMS system did you use? (or is it internally developed). We're in the process of trying to integrate Magnolia into Struts 2, which wasn't really designed for the task. Thanks. (*Chris*) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Brian Pontarelli wrote: Jeromy Evans wrote: While on the topic, with respect to defaults/exceptions etc, can I ask the specification addresses how invalid URLs are handled. In the current implementation (0.18) invalid URL's return (unexpected?) success results. They shouldn't unless it finds a result that will handle the URL. If it can't find one it will throw the standard exception, which should be processed as it currently is. I've tested default actions/results as well as exception and 404/500 handling and it all works fine. If you could give an example that is not working for you, I can look into it. I see. In my case as I had an IndexAction in the base package and a result for the success result (/index.jsp) and no default action, instead of generating a 404 when entering an arbitrary path, it executes the root IndexAction (the index action in the default package). In the case of MailReader, if you enter http://localhost:8080/an/arbitary/url it will attempt execute the default action (Support) but returns a 404 because no result corresponds to SUCCESS. This case seems okay as a default action was defined and subsequently executed. My case can be replicated in the MailReader however by adding a no-op IndexAction in root namespace and removing the default-action-ref. After making this change: http://localhost:8080/index shows the index http://localhost:8080/an/arbitary/url also shows the root index and after showing the index for an arbitrary URL, all relative links become invalid: ie. clicking on "Log into MailReader" successfully performs a GET to http://localhost:8080/an/arbitary/url/login-input/ and shows the index again Namespace precedence also seems to be an issue when handling invalid paths and needs to be specified: ie. Assuming pets.IndexAction exists: http://www.example.com/petsmaps to pets.IndexAction (as expected); but the URL: http://www.example.com/pets/dogs maps to /IndexAction if pets.dogs.IndexAction does not exist rather than pets.IndexAction or an exception (which is expected?) This is a bit confusing. So, /pets should redirect /pets/ and that should render the /pets/index action. However, /pets/dogs should error out unless there is an action named dogs in /pets or an index action in /pets/dogs. If that isn't working it seems like a bug. Here's the same example in the unmodified MailReader: Register a user and login: GET http://localhost:8080/register/update!input allows you to edit your current profile (okay) GET http://localhost:8080/register/ shows the root index page (the one at /index) (not okay) GET http://localhost:8080/register/login-input/register/login-input/register/login-input/ shows the root index page (not okay) GET http://localhost:8080/register/update!input/login redirects to GET http://localhost:8080/register/update!input/menu (not okay) GET http://localhost:8080/subscribe/update!input/logout redirects to GET http://localhost:8080/subscribe/update!input/index (not okay) It seems to be a bit too eager matching actions in the root namespace. Anyway, I wasn't intending to raise bugs. As I mentioned already, I think this is going to be a great change, but the exception handling and defaults need to be examined a little closer. Hope that helps, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA
Matt Raible wrote: The Roller / Struts 2 BOF is on at ApacheCon! Wednesday night, 8:30-9:30 in Room 3. I assume it's kosher to come to this even if I'm not attending ApacheCon? -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA
The Roller / Struts 2 BOF is on at ApacheCon! Wednesday night, 8:30-9:30 in Room 3. http://wiki.apache.org/apachecon/BirdsOfaFeatherUs07 Dave said he'd do a presentation, but according to the ApacheCon folks there won't be any projectors available. Anyone in ATL have a projector we could borrow? http://rollerweblogger.org/roller/entry/apachecon_roller_and_struts_2 Don has also been successful (I think) in getting Atlassian to sponsor the beer! Come one, come all - it should be a good time for sure. Matt On 10/4/07, Matt Raible <[EMAIL PROTECTED]> wrote: > I've always called them BOFs, and they generally operate like a BOF - > except attendees enjoy themselves because there's beer and more people > generally show up. ;-) > > Matt > > On 10/4/07, Don Brown <[EMAIL PROTECTED]> wrote: > > So this will be more of a Struts party then? I can see if I can get > > Atlassian to put some money/beer in the pot. > > > > Don > > > > On 10/5/07, Matt Raible <[EMAIL PROTECTED]> wrote: > > > I'll contact the conference organizers to see what's the best night > > > (thurs or fri) and then proceed to contact the hotel (or a nearby > > > bar?) to get some cost estimates. From there, I'll start contacting > > > potential sponsors. > > > > > > Sound good? If anyone wants to assist, let me know. > > > > > > Matt > > > > > > > > > On 10/4/07, Don Brown <[EMAIL PROTECTED]> wrote: > > > > Yeah, we'll do a BOF, although they are usually pretty low key, I'm up > > > > for kicking it up a notch, especially if there is free beer :) > > > > > > > > Don > > > > > > > > On 10/4/07, Matt Raible <[EMAIL PROTECTED]> wrote: > > > > > On 10/3/07, Dale Newfield <[EMAIL PROTECTED]> wrote: > > > > > > Ted Husted wrote: > > > > > > > ApacheCon US 2007 Atlanta GA, November 12-16. > > > > > > > > > > > > While I'm not rich enough to attend this event, I do live in > > > > > > Atlanta, > > > > > > and I'd welcome the opportunity to buy a round of beers for the > > > > > > folks > > > > > > responsible for Struts2 and AppFuse (Matt, do you read the > > > > > > struts-dev > > > > > > list?)... > > > > > > > > > > I do read this list and would love to have a beer - especially if > > > > > you're buying. ;-) > > > > > > > > > > Is there a Struts BOF planned? If so, we should find a sponsor to > > > > > provide beers. I've done this in the past and it's always been well > > > > > received. > > > > > > > > > > Matt > > > > > > > > > > > > > > > > > ...is this the type of convention where people spend the evenings > > > > > > out > > > > > > having nice meals/drinks with colleagues, or where people spend the > > > > > > evenings quietly hacking away on laptops? > > > > > > > > > > > > -Dale Newfield > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://raibledesigns.com > > > > > > > > > > - > > > > > 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] > > > > > > > > > > > > > > > > > -- > > > http://raibledesigns.com > > > > > > - > > > 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] > > > > > > > -- > http://raibledesigns.com > -- http://raibledesigns.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [ANN] Three Struts Tutorials or Presentations at ApacheCon US 2007 Atlanta GA
I won't tell if you don't. ;-) On 11/2/07, Dale Newfield <[EMAIL PROTECTED]> wrote: > Matt Raible wrote: > > The Roller / Struts 2 BOF is on at ApacheCon! > > > > Wednesday night, 8:30-9:30 in Room 3. > > I assume it's kosher to come to this even if I'm not attending ApacheCon? > > -Dale > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://raibledesigns.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
