Re: Proposed enhancement to
Hi Martin, +1 I think it is a really good idea and I was about to ask for a feature like this. keep going ;-) simon Martin Cooper schrieb: > > I posted this a few weeks ago as a patch, when it should more properly have > been a proposal. Here, then, is the proposal: > > A problem with the current tag is that the only way to > specify the message resource key dynamically is by using a JSP expression. > This leads to the use of the following pattern: > > type="java.lang.String"/> > > > An alternative is to have the Action look up the key and set the resulting > string value in the property for use on the JSP page via . This > doesn't feel right, because the responsibility for looking up the > appropriately localized text is then divided between the Action and the JSP > page. > > By enhancing the tag to allow it to obtain the message > resource key from a bean property, we can simplify the above example to: > > > > Here, the 'name' and 'property' attributes are used to obtain the message > resource key from a bean. That key is then used as if it had been specified > using the 'key' attribute. > > I believe this proposal would enhance the i18n functionality of Struts by > allowing dynamic specification of messages, while delegating the resolution > of the actual message text to the view. > > Comments? > > -- > Martin Cooper
Re: Proposed enhancement to
Yes, that is exactly what I intended. -- Martin Cooper - Original Message - From: "Oleg V Alexeev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 11:11 PM Subject: Re: Proposed enhancement to > Hello Martin, > > +1 > > I think it must work at standard struts way - > > > > > and existing one - > > > > Tuesday, June 19, 2001, 9:49:56 AM, you wrote: > > MC> I posted this a few weeks ago as a patch, when it should more properly have > MC> been a proposal. Here, then, is the proposal: > > MC> A problem with the current tag is that the only way to > MC> specify the message resource key dynamically is by using a JSP expression. > MC> This leads to the use of the following pattern: > > MC> MC> type="java.lang.String"/> > MC> > > MC> An alternative is to have the Action look up the key and set the resulting > MC> string value in the property for use on the JSP page via . This > MC> doesn't feel right, because the responsibility for looking up the > MC> appropriately localized text is then divided between the Action and the JSP > MC> page. > > MC> By enhancing the tag to allow it to obtain the message > MC> resource key from a bean property, we can simplify the above example to: > > MC> > > MC> Here, the 'name' and 'property' attributes are used to obtain the message > MC> resource key from a bean. That key is then used as if it had been specified > MC> using the 'key' attribute. > > MC> I believe this proposal would enhance the i18n functionality of Struts by > MC> allowing dynamic specification of messages, while delegating the resolution > MC> of the actual message text to the view. > > MC> Comments? > > MC> -- > MC> Martin Cooper > > > > > > > -- > Best regards, > Olegmailto:[EMAIL PROTECTED] > >
PROPOSAL: Enhancement of templates
Hello struts-dev, Now I use next scheme to pass parameters to the template page - --- page - and check parameter 'chapter' in template. -- template - ... - But I think that this approach is not so flexible because of direct query string editing. For my mind constructions listed below is more preferable - --- page - -- template - - How about it? -- Best regards, Oleg mailto:[EMAIL PROTECTED]
Re: Proposed enhancement to
Hello Martin, +1 I think it must work at standard struts way - and existing one - Tuesday, June 19, 2001, 9:49:56 AM, you wrote: MC> I posted this a few weeks ago as a patch, when it should more properly have MC> been a proposal. Here, then, is the proposal: MC> A problem with the current tag is that the only way to MC> specify the message resource key dynamically is by using a JSP expression. MC> This leads to the use of the following pattern: MC> type="java.lang.String"/> MC> MC> An alternative is to have the Action look up the key and set the resulting MC> string value in the property for use on the JSP page via . This MC> doesn't feel right, because the responsibility for looking up the MC> appropriately localized text is then divided between the Action and the JSP MC> page. MC> By enhancing the tag to allow it to obtain the message MC> resource key from a bean property, we can simplify the above example to: MC> MC> Here, the 'name' and 'property' attributes are used to obtain the message MC> resource key from a bean. That key is then used as if it had been specified MC> using the 'key' attribute. MC> I believe this proposal would enhance the i18n functionality of Struts by MC> allowing dynamic specification of messages, while delegating the resolution MC> of the actual message text to the view. MC> Comments? MC> -- MC> Martin Cooper -- Best regards, Olegmailto:[EMAIL PROTECTED]
Proposed enhancement to
I posted this a few weeks ago as a patch, when it should more properly have been a proposal. Here, then, is the proposal: A problem with the current tag is that the only way to specify the message resource key dynamically is by using a JSP expression. This leads to the use of the following pattern: An alternative is to have the Action look up the key and set the resulting string value in the property for use on the JSP page via . This doesn't feel right, because the responsibility for looking up the appropriately localized text is then divided between the Action and the JSP page. By enhancing the tag to allow it to obtain the message resource key from a bean property, we can simplify the above example to: Here, the 'name' and 'property' attributes are used to obtain the message resource key from a bean. That key is then used as if it had been specified using the 'key' attribute. I believe this proposal would enhance the i18n functionality of Struts by allowing dynamic specification of messages, while delegating the resolution of the actual message text to the view. Comments? -- Martin Cooper
Re[4]: [PROPOSAL] Struts Extensions
Hello Niall, Tuesday, June 19, 2001, 7:59:53 AM, you wrote: NP> Oleg, NP> Do you not think that if there was easier/standard mechanism in Struts to NP> initialise resources it would be valid to use that for your bean-factory, NP> even if you still needed to sub-class ActionServlet to do your NP> processPreprocess stuff? Standart init mechanism - yes, of course. But I talk about more abilities to extend struts functionality without extending ActionServlet. I think that struts needs simple and flexible engine to work with plugins. Of course some extensions can be turn on as external servlets (load its own resources, init some application scope objects and stay here), but there are tasks with needs to perform activity at key positions of request processing in ActionServlet. For example - before or after form validation, before or after call of perform() method. To support flexible extensions mechanism in struts there must exist such additions as - 1. Load all struts-config to the memory by ActionServlet only. Now it needs to extend initDigester() to process additional configuration sections in struts-config. May be it needs to supply additional info about intercept of extension related info (class name, for example). 2. Register extension classes in struts-config and instantiate it at servlet load time. 3. Add ability for extensions to register to some request processing moments. For example - for form processing, for post-, pre-perfom processing. On the whole - a. Full application config contains in struts-config and this config can be processed without ActionServlet extending, b. ActionServlet can load so named 'extensions' (read info about it from struts-config, create class instance, call init method and pass to it servlet config object) c. Each extension can be described in struts-config as activity-subscriber to get control at pre- form validation moment, for example (ActionServlet can accumulate such info from struts-config and at key points call registered intercepters). >> -Original Message- >> From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] >> Sent: 11 June 2001 21:00 >> To: [EMAIL PROTECTED] >> Subject: Re[2]: [PROPOSAL] Struts Extensions >> >> >> Hello Martin, >> >> But how about such situation as follows. I can store bean-factory >> object in application scope. I can use it in any action to perform >> bean producing. But main idea of bean-factory is to perform >> _automatic_ bean generation by name of the action. For example - in >> struts-config or in external config file I define mapping between >> action and some kind of bean. All beans from mappings must be created to >> be ready to use it in appropriate actio at request processing phase before >> Action.perfom method call. How can I do it without >> extending ActionServlet? I think there is one way to implement this >> with current struts API - extend ActionServlet and redefine >> processPreprocess method to perform all 'before Action.perfom' stuff. >> >> So struts control-gear can be extended to to register external classes >> or servlets to perform some activity at key points of request >> processing - ActionForm processing, Action processing, etc. Now it can >> be implemented only via ActionServlet extending - is not scalable >> solution for my mind. >> >> Sunday, June 10, 2001, 11:20:22 PM, you wrote: >> >> MC> I like this idea. I think David is right - a lot of people do extend >> MC> ActionServlet just to initialize resources. While this idea >> wouldn't remove >> MC> all of the reasons to build a custom servlet, it would provide a >> MC> systematic - and potentially simpler - way to solve a common problem. >> >> MC> -- >> MC> Martin Cooper >> >> >> MC> - Original Message - >> MC> From: "David Winterfeldt" <[EMAIL PROTECTED]> >> MC> To: <[EMAIL PROTECTED]> >> MC> Sent: Sunday, June 10, 2001 11:37 AM >> MC> Subject: Re: [PROPOSAL] Struts Extensions >> >> >> >> It might be nice if there was a way to register an >> >> interface with the ActionServlet in the config file >> >> for it to initialize a service. All the >> >> ValidatorServlet I made does is parse the xml file >> >> with the Digester and put an object into application >> >> scope. If a class could be registered, then a servlet >> >> wouldn't hang around for no reason and it wouldn't >> >> need to be defined in the web.xml. And it sounds like >> >> a lot of people extend the ActionServlet just to >> >> initialize resources on startup. >> >> >> >> David >> >> >> >> --- Ted Husted <[EMAIL PROTECTED]> wrote: >> >> > I agree that most extensions would be best written >> >> > as independant >> >> > servlets that plug into the application alongside >> >> > the Struts >> >> > ActionServlet. Though, I'm not sure they would need >> >> > to register with the >> >> > ActionServlet to access other parts of the >> >> > framework. >> >> > >> >> > I haven't worked with the Digester directly, but >> >> > most of the
Re: Struts 1.0 Released - Looking forward to 1.1!!!!!!!
Niall, Regarding "auto-generating a subscript", what do you have in mind? The indexId attribute was added to the iterate tag recently (just before Struts 1.0) so that a scripting variable can be created containing the value of the current index. However, from the description in the TODO list, I'm not sure if that's the same thing or not. Thanks! -- Martin Cooper - Original Message - From: "Niall Pemberton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 6:46 PM Subject: Struts 1.0 Released - Looking forward to 1.1!!! > Congratulations and thank you for Struts 1.0 - a great product. > > Now I know you guys deserve a well earned rest now Struts 1.0 is released, > but what sort of timescale do you envisage work starting on 1.1? > > I am particularly interested for starters in: > > 1) ActionForms with dynamic properties. > 2) If/Else and Switch/Case tags (I submitted tags which do this to the dev > list a while ago). > 3) Improved Iteration Support - auto-generating a subscript. > > These areas are currently unassigned on the ToDo list and presumably need a > committer to take control. If someone is assigned I am more than willing to > contribute to these (and other) areas. > > Niall > > > -Original Message- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > Sent: 16 June 2001 01:23 > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: [ANNOUNCEMENT] Struts 1.0 (Final) Released > > > > > > As promised at JavaOne, the Struts project team is proud to announce the > > availability of Version 1.0 (final release) of the Struts Framework. The > > binary distribution is available at: > > > > http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/ > > > > and the source distribution is available at: > > > > http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/ > > > > > > Craig McClanahan > > > > >
RE: Re[2]: [PROPOSAL] Struts Extensions
Oleg, Do you not think that if there was easier/standard mechanism in Struts to initialise resources it would be valid to use that for your bean-factory, even if you still needed to sub-class ActionServlet to do your processPreprocess stuff? This gets my vote. Niall > -Original Message- > From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] > Sent: 11 June 2001 21:00 > To: [EMAIL PROTECTED] > Subject: Re[2]: [PROPOSAL] Struts Extensions > > > Hello Martin, > > But how about such situation as follows. I can store bean-factory > object in application scope. I can use it in any action to perform > bean producing. But main idea of bean-factory is to perform > _automatic_ bean generation by name of the action. For example - in > struts-config or in external config file I define mapping between > action and some kind of bean. All beans from mappings must be created to > be ready to use it in appropriate actio at request processing phase before > Action.perfom method call. How can I do it without > extending ActionServlet? I think there is one way to implement this > with current struts API - extend ActionServlet and redefine > processPreprocess method to perform all 'before Action.perfom' stuff. > > So struts control-gear can be extended to to register external classes > or servlets to perform some activity at key points of request > processing - ActionForm processing, Action processing, etc. Now it can > be implemented only via ActionServlet extending - is not scalable > solution for my mind. > > Sunday, June 10, 2001, 11:20:22 PM, you wrote: > > MC> I like this idea. I think David is right - a lot of people do extend > MC> ActionServlet just to initialize resources. While this idea > wouldn't remove > MC> all of the reasons to build a custom servlet, it would provide a > MC> systematic - and potentially simpler - way to solve a common problem. > > MC> -- > MC> Martin Cooper > > > MC> - Original Message - > MC> From: "David Winterfeldt" <[EMAIL PROTECTED]> > MC> To: <[EMAIL PROTECTED]> > MC> Sent: Sunday, June 10, 2001 11:37 AM > MC> Subject: Re: [PROPOSAL] Struts Extensions > > > >> It might be nice if there was a way to register an > >> interface with the ActionServlet in the config file > >> for it to initialize a service. All the > >> ValidatorServlet I made does is parse the xml file > >> with the Digester and put an object into application > >> scope. If a class could be registered, then a servlet > >> wouldn't hang around for no reason and it wouldn't > >> need to be defined in the web.xml. And it sounds like > >> a lot of people extend the ActionServlet just to > >> initialize resources on startup. > >> > >> David > >> > >> --- Ted Husted <[EMAIL PROTECTED]> wrote: > >> > I agree that most extensions would be best written > >> > as independant > >> > servlets that plug into the application alongside > >> > the Struts > >> > ActionServlet. Though, I'm not sure they would need > >> > to register with the > >> > ActionServlet to access other parts of the > >> > framework. > >> > > >> > I haven't worked with the Digester directly, but > >> > most of the other > >> > Struts services are already exposed through the > >> > application context. > >> > Custom tags, for example, already access the Action > >> > Mappings this way. > >> > So any other servlet in the application (since > >> > that's all JSP's are) > >> > should be able to do the same. > >> > > >> > Another example is the Generic Connection Pool. The > >> > datasource is > >> > exposed through the application context and other > >> > services, like the > >> > TagLibs JDBC tags, can use the pool without knowing > >> > anything about > >> > Struts (or Struts knowing anything about them). > >> > > >> > So I would suggest that if there are other services > >> > that an extension > >> > needs to share that we expose them through the > >> > Application context. > >> > > >> > Oleg V Alexeev wrote: > >> > > >> > > To support flexible extensions mechanism for > >> > struts there are can be > >> > > made some additions to the core structure of the > >> > framework - > >> > > > >> > > 1. Add ability to register components or external > >> > servlets (at > >> > >application level) via struts-config file. > >> > > 2. Give such external components or servlets > >> > ability to use action > >> > >mappings database from ActionServlet. > >> > > 3. Extend core API of struts to support pluggable > >> > extensions - for > >> > >example use event model or direct calls via > >> > registrations in action > >> > >mappiongs database. > >> > > > >> > > The best way for my mind is to write external > >> > servlets, register it in > >> > > struts ActionServlet and use it as external > >> > services. This approach > >> > > can be useful in case of mutliple ActionServlet > >> > instances in one > >> > > application - every ActionServlet subscribe to use > >> > and uses some > >> > > amount of external services. > >> > >> > >> __
Re: Client/Server Side Validation for Struts 1.1
What do you mean by "converted into the format of the system"? Do you mean the object and not the String representation in the ActionForm? Or are you refering to the part where I talk about associating a locale to a phone number? Expand on what you were saying if this doesn't cover it, but the initial validations would be to get required fields filled in and in the correct format to be converted to objects. For example, there would be no reason to check that a social security number is in your system until it is a well formed social security number. Then you can convert your ActionForm to a JavaBean with correct java types (java.util.Date, etc.) and with the typed JavaBean you can then pass that to a validation bean, an EJB, or any other server side resource. And if you have a multi-tier distributed system you would ideally want to get the information filled in properly before you send it to an EJB. Or if you mean that there are a lot of permutations for phone numbers or dates, there are. If we model things to take a pattern (MM/dd/ or (###) ###-), then one type of class can perform the validation/conversion based on the pattern. A date can get converted to a date for checking if it falls in a range, is within the last seven days, etc., but a phone number is phone number and can't really be converted into a standard format like a date. David --- Jonathan Asbell <[EMAIL PROTECTED]> wrote: > Hi Dave. I really think (and tell me what you > think) that all special > formatting shoudl eventually be converted into the > format of the system it > is running on, THEN validated. Otherwise you have > to design a gazillion > permutations to validate. We could instead make > various converters for each > situation as needed, and one central validation > package. > > - Original Message - > From: "David Winterfeldt" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, June 18, 2001 2:26 PM > Subject: RE: Client/Server Side Validation for > Struts 1.1 > > > > I've still been continuing work on the Struts > > Validator > (http://home.earthlink.net/~dwinterfeldt/) > > in it's present form, but I've been thinking about > the > > discussion under this thread and the best way to > > integrate these ideas with what I've done so far. > It > > seems like it is best to keep everything as > separate > > components and just make sure they work together. > The > > Mapper is separate. There should be a general > > validation/transformation package that you can > pass in > > a String and it can create on object for you and > throw > > an Exception if it can't (based on > java.text.Format as > > you suggested). This package could then be used > for > > the Mapper, validation, and formatting. So you > should > > be able to define that a date should be > "MM/dd/" > > and this would be used for formatting of the date > > object as it is converted to a String in the > > ActionForm and also would be used for validation > and > > after validation for the transformation back to a > date > > object. But as it was discussed, the way the > standard > > message resources work (from a region down to a > > language) doesn't make sense for a phone number > that > > should be associated with region and has nothing > to do > > with the language. I was thinking that if > resources > > like phone numbers were loaded based on a location > and > > you could reference them from the validation.xml > that > > might work. > > > > > depends="mask"> > > > > key="registrationForm.phone.displayname"/> > > > > > > The 'trans' prefix would represent that the value > > should be retreived from the transformation > resources > > for the US phone number format. Or possibly if > you > > don't specify a country it would use the one from > the > > locale in session scope. > > > > David > > > > > > --- Rey Francois <[EMAIL PROTECTED]> wrote: > > > David, > > > > > > We don't generate any classes yet, but the > intention > > > would be to do so for > > > ActionForms at a later stage. > > > We would use a separate XML file, because the > > > mapper-config.xml contains > > > mappings, not bean definitions (mappings define > > > many-to-many relationships > > > between fields of several objects). > > > I have of course the source for this mapper > > > framework. If the decision was > > > only mine I would be pleased to share it. I need > to > > > discuss this with other > > > people within my company who should also be > involved > > > in this decision. I > > > hope to get this sorted out this week... > > > > > > Are you still exploring solutions for a > validation > > > framework? > > > > > > Fr. > > > > > > -Original Message- > > > From: David Winterfeldt > > > [mailto:[EMAIL PROTECTED]] > > > Sent: 15 June 2001 14:31 > > > To: [EMAIL PROTECTED] > > > Subject: RE: Client/Server Side Validation for > > > Struts 1.1 > > > > > > > > > I just wanted to put this out there to see what > > > people >
Re: Client/Server Side Validation for Struts 1.1
Hi Dave. I really think (and tell me what you think) that all special formatting shoudl eventually be converted into the format of the system it is running on, THEN validated. Otherwise you have to design a gazillion permutations to validate. We could instead make various converters for each situation as needed, and one central validation package. - Original Message - From: "David Winterfeldt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 2:26 PM Subject: RE: Client/Server Side Validation for Struts 1.1 > I've still been continuing work on the Struts > Validator (http://home.earthlink.net/~dwinterfeldt/) > in it's present form, but I've been thinking about the > discussion under this thread and the best way to > integrate these ideas with what I've done so far. It > seems like it is best to keep everything as separate > components and just make sure they work together. The > Mapper is separate. There should be a general > validation/transformation package that you can pass in > a String and it can create on object for you and throw > an Exception if it can't (based on java.text.Format as > you suggested). This package could then be used for > the Mapper, validation, and formatting. So you should > be able to define that a date should be "MM/dd/" > and this would be used for formatting of the date > object as it is converted to a String in the > ActionForm and also would be used for validation and > after validation for the transformation back to a date > object. But as it was discussed, the way the standard > message resources work (from a region down to a > language) doesn't make sense for a phone number that > should be associated with region and has nothing to do > with the language. I was thinking that if resources > like phone numbers were loaded based on a location and > you could reference them from the validation.xml that > might work. > > depends="mask"> > > > > > The 'trans' prefix would represent that the value > should be retreived from the transformation resources > for the US phone number format. Or possibly if you > don't specify a country it would use the one from the > locale in session scope. > > David > > > --- Rey Francois <[EMAIL PROTECTED]> wrote: > > David, > > > > We don't generate any classes yet, but the intention > > would be to do so for > > ActionForms at a later stage. > > We would use a separate XML file, because the > > mapper-config.xml contains > > mappings, not bean definitions (mappings define > > many-to-many relationships > > between fields of several objects). > > I have of course the source for this mapper > > framework. If the decision was > > only mine I would be pleased to share it. I need to > > discuss this with other > > people within my company who should also be involved > > in this decision. I > > hope to get this sorted out this week... > > > > Are you still exploring solutions for a validation > > framework? > > > > Fr. > > > > -Original Message- > > From: David Winterfeldt > > [mailto:[EMAIL PROTECTED]] > > Sent: 15 June 2001 14:31 > > To: [EMAIL PROTECTED] > > Subject: RE: Client/Server Side Validation for > > Struts 1.1 > > > > > > I just wanted to put this out there to see what > > people > > think since I took the time to look at how Barracuda > > worked. I like the idea of not having two classes > > (ActionForm and a data bean), but I guess there will > > be a few different tools to autogenerate these as > > time > > goes by. Do you autogenerate classes based on the > > xml > > file? You have all the information in the xml file > > to > > make this possible, right? I think most of the > > issues > > you mention could be worked around, but you're > > Mapper > > idea is much more flexible. Is any source for what > > you've done available to look at or is it > > proprietary > > (I do have the xml file you sent to the list)? > > > > David > > > > --- Rey Francois <[EMAIL PROTECTED]> wrote: > > > David, > > > > > > A few remarks: > > > - I'm not sure that we should loose the value > > > entered by the user once the > > > transformation is done. Although I see the > > argument > > > that once transformed > > > the string value is most likely redundant, there > > may > > > be cases when it is > > > still useful. Also, unless you're able to make the > > > reverse transformation > > > and produce the exact same string as the user has > > > entered, further display > > > of the form may confuse a user when the displayed > > > fields differ from what he > > > has entered. I would be more in favor of an > > > ActionForm that is just a > > > placeholder for values entered by the user, like > > it > > > is at present. > > > - Having only one validator per property is a > > > limitation. We should be able > > > to have more than one like you already support in > > > your current framework. We > > > should also think about validation across several > > > fields. For example, in > > >
Re: The documentation, xml, and stylesheets
I am at a loss as to how to respond to this. You obviously work alone - Original Message - From: "Michael Westbay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 8:27 PM Subject: Re: The documentation, xml, and stylesheets > Asbell-san wrote: > > > Mike, I am forced to work with xslt every day, [...] > > It sounds to me like you're one of those many people who majored in something > that had nothing to do with computers, then found yourself in the IT field. > I was a Computer Science major. I taught myself HTML, XML, SGML, XSL, and > the rest of the alphabet soup in my own time after work simply because I > found them fascinating. > > > [...] and each day I find a new > > reason to say "what in the WORLD do people see in this?!". It has its > > place in changing from schema to schema, but who want to get so deep into a > > technology which is very hard to control, and in complex schemas consumes > > more effort than it is worth to get what you want out of it. > > Let me venture another guess. You're working primarily with poorly > documented and or thought out DTDs that are ever changing as more > functionality is desired, leaving you to constantly update the style sheet > transforms to satisfy the whims of your boss. > > First of all, getting in deep with the technology gives one a better > understanding of it. I started learning HTML in 1995 armed with Mosaic and > my trusty vi editor. GUIs are nice, but IMHO, they separate the creator from > the underlying technologies too much. I'd rather know what's going on under > the hood. Why does a page render the way it does. Getting a good > fundamental knowledge of the low level technologies allows me to spot and fix > problems quickly. It also allows for better efficiency when using the > technologies. > > With a better understanding, the technologies are not hard to control. A > well written schema, even a very complex one (like DocBook) is well worth the > effort of getting a good understanding of the underlying technologies. > > As Winterfeldt-san pointed out, the whole XML/XSL bit it may be overkill for > a few scattered unrelated documents. But when the documentation starts > increasing, a well thought out schema for allowing flexible access to what > would be a mountian load of dead trees saves a great deal in the long run. > > I don't know if my evengilism of a technology can change your mind. We > obviously have very different backgrounds (I was the only one in my English > classes to turn in papers written in LaTeX [edited in vi, of course] - > everyone else used WordPerfect or [gasp!] a typewriter). And our jobs seem > to give different levels of satisfaction: I'd study this stuff on my own if > I didn't get to work with it anyway, whereas you're "forced to work with xslt > every day." > > I think it's great that you're volunteering to help with the documentation. > But I also think it's strange that you hadn't gone through what is there and > seen how it is generated from XML via XSLT. I would have expected some sort > of professional curiosity as to how others deal with documentation issues, > since that seems to be your line of work. But then, maybe it's me applying > my own drive to learn more ways of doing things to improve my own skills and > the way I do my job. (Sorry, I forget sometimes that not everyone takes a > job in the tech field by choice.) > > -- > Michael Westbay > Work: Beacon-IT http://www.beacon-it.co.jp/ > Home: http://www.seaple.icc.ne.jp/~westbay > Commentary: http://www.japanesebaseball.com/ >
Struts 1.0 Released - Looking forward to 1.1!!!!!!!
Congratulations and thank you for Struts 1.0 - a great product. Now I know you guys deserve a well earned rest now Struts 1.0 is released, but what sort of timescale do you envisage work starting on 1.1? I am particularly interested for starters in: 1) ActionForms with dynamic properties. 2) If/Else and Switch/Case tags (I submitted tags which do this to the dev list a while ago). 3) Improved Iteration Support - auto-generating a subscript. These areas are currently unassigned on the ToDo list and presumably need a committer to take control. If someone is assigned I am more than willing to contribute to these (and other) areas. Niall > -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: 16 June 2001 01:23 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [ANNOUNCEMENT] Struts 1.0 (Final) Released > > > As promised at JavaOne, the Struts project team is proud to announce the > availability of Version 1.0 (final release) of the Struts Framework. The > binary distribution is available at: > > http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/ > > and the source distribution is available at: > > http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/ > > > Craig McClanahan > >
Re: The documentation, xml, and stylesheets
On Mon, 18 Jun 2001, Barry Glasco wrote: > You are a Jack Ass! That is the most technical way > I could think of putting it. > Disagreements over technologies need not devolve into personal attacks. One of the refreshing things about the Struts community has been the relative absence of stuff like this. Let's keep it that way, and avoid this kind of comment on the mailing lists. Craig
Re: The documentation, xml, and stylesheets
You are a Jack Ass! That is the most technical way I could think of putting it. Later - Original Message - From: "Michael Westbay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 8:27 PM Subject: Re: The documentation, xml, and stylesheets > Asbell-san wrote: > > > Mike, I am forced to work with xslt every day, [...] > > It sounds to me like you're one of those many people who majored in something > that had nothing to do with computers, then found yourself in the IT field. > I was a Computer Science major. I taught myself HTML, XML, SGML, XSL, and > the rest of the alphabet soup in my own time after work simply because I > found them fascinating. > > > [...] and each day I find a new > > reason to say "what in the WORLD do people see in this?!". It has its > > place in changing from schema to schema, but who want to get so deep into a > > technology which is very hard to control, and in complex schemas consumes > > more effort than it is worth to get what you want out of it. > > Let me venture another guess. You're working primarily with poorly > documented and or thought out DTDs that are ever changing as more > functionality is desired, leaving you to constantly update the style sheet > transforms to satisfy the whims of your boss. > > First of all, getting in deep with the technology gives one a better > understanding of it. I started learning HTML in 1995 armed with Mosaic and > my trusty vi editor. GUIs are nice, but IMHO, they separate the creator from > the underlying technologies too much. I'd rather know what's going on under > the hood. Why does a page render the way it does. Getting a good > fundamental knowledge of the low level technologies allows me to spot and fix > problems quickly. It also allows for better efficiency when using the > technologies. > > With a better understanding, the technologies are not hard to control. A > well written schema, even a very complex one (like DocBook) is well worth the > effort of getting a good understanding of the underlying technologies. > > As Winterfeldt-san pointed out, the whole XML/XSL bit it may be overkill for > a few scattered unrelated documents. But when the documentation starts > increasing, a well thought out schema for allowing flexible access to what > would be a mountian load of dead trees saves a great deal in the long run. > > I don't know if my evengilism of a technology can change your mind. We > obviously have very different backgrounds (I was the only one in my English > classes to turn in papers written in LaTeX [edited in vi, of course] - > everyone else used WordPerfect or [gasp!] a typewriter). And our jobs seem > to give different levels of satisfaction: I'd study this stuff on my own if > I didn't get to work with it anyway, whereas you're "forced to work with xslt > every day." > > I think it's great that you're volunteering to help with the documentation. > But I also think it's strange that you hadn't gone through what is there and > seen how it is generated from XML via XSLT. I would have expected some sort > of professional curiosity as to how others deal with documentation issues, > since that seems to be your line of work. But then, maybe it's me applying > my own drive to learn more ways of doing things to improve my own skills and > the way I do my job. (Sorry, I forget sometimes that not everyone takes a > job in the tech field by choice.) > > -- > Michael Westbay > Work: Beacon-IT http://www.beacon-it.co.jp/ > Home: http://www.seaple.icc.ne.jp/~westbay > Commentary: http://www.japanesebaseball.com/ > >
Re: The documentation, xml, and stylesheets
Asbell-san wrote: > Mike, I am forced to work with xslt every day, [...] It sounds to me like you're one of those many people who majored in something that had nothing to do with computers, then found yourself in the IT field. I was a Computer Science major. I taught myself HTML, XML, SGML, XSL, and the rest of the alphabet soup in my own time after work simply because I found them fascinating. > [...] and each day I find a new > reason to say "what in the WORLD do people see in this?!". It has its > place in changing from schema to schema, but who want to get so deep into a > technology which is very hard to control, and in complex schemas consumes > more effort than it is worth to get what you want out of it. Let me venture another guess. You're working primarily with poorly documented and or thought out DTDs that are ever changing as more functionality is desired, leaving you to constantly update the style sheet transforms to satisfy the whims of your boss. First of all, getting in deep with the technology gives one a better understanding of it. I started learning HTML in 1995 armed with Mosaic and my trusty vi editor. GUIs are nice, but IMHO, they separate the creator from the underlying technologies too much. I'd rather know what's going on under the hood. Why does a page render the way it does. Getting a good fundamental knowledge of the low level technologies allows me to spot and fix problems quickly. It also allows for better efficiency when using the technologies. With a better understanding, the technologies are not hard to control. A well written schema, even a very complex one (like DocBook) is well worth the effort of getting a good understanding of the underlying technologies. As Winterfeldt-san pointed out, the whole XML/XSL bit it may be overkill for a few scattered unrelated documents. But when the documentation starts increasing, a well thought out schema for allowing flexible access to what would be a mountian load of dead trees saves a great deal in the long run. I don't know if my evengilism of a technology can change your mind. We obviously have very different backgrounds (I was the only one in my English classes to turn in papers written in LaTeX [edited in vi, of course] - everyone else used WordPerfect or [gasp!] a typewriter). And our jobs seem to give different levels of satisfaction: I'd study this stuff on my own if I didn't get to work with it anyway, whereas you're "forced to work with xslt every day." I think it's great that you're volunteering to help with the documentation. But I also think it's strange that you hadn't gone through what is there and seen how it is generated from XML via XSLT. I would have expected some sort of professional curiosity as to how others deal with documentation issues, since that seems to be your line of work. But then, maybe it's me applying my own drive to learn more ways of doing things to improve my own skills and the way I do my job. (Sorry, I forget sometimes that not everyone takes a job in the tech field by choice.) -- Michael Westbay Work: Beacon-IT http://www.beacon-it.co.jp/ Home: http://www.seaple.icc.ne.jp/~westbay Commentary: http://www.japanesebaseball.com/
RE: Client/Server Side Validation for Struts 1.1
I've still been continuing work on the Struts
Validator (http://home.earthlink.net/~dwinterfeldt/)
in it's present form, but I've been thinking about the
discussion under this thread and the best way to
integrate these ideas with what I've done so far. It
seems like it is best to keep everything as separate
components and just make sure they work together. The
Mapper is separate. There should be a general
validation/transformation package that you can pass in
a String and it can create on object for you and throw
an Exception if it can't (based on java.text.Format as
you suggested). This package could then be used for
the Mapper, validation, and formatting. So you should
be able to define that a date should be "MM/dd/"
and this would be used for formatting of the date
object as it is converted to a String in the
ActionForm and also would be used for validation and
after validation for the transformation back to a date
object. But as it was discussed, the way the standard
message resources work (from a region down to a
language) doesn't make sense for a phone number that
should be associated with region and has nothing to do
with the language. I was thinking that if resources
like phone numbers were loaded based on a location and
you could reference them from the validation.xml that
might work.
The 'trans' prefix would represent that the value
should be retreived from the transformation resources
for the US phone number format. Or possibly if you
don't specify a country it would use the one from the
locale in session scope.
David
--- Rey Francois <[EMAIL PROTECTED]> wrote:
> David,
>
> We don't generate any classes yet, but the intention
> would be to do so for
> ActionForms at a later stage.
> We would use a separate XML file, because the
> mapper-config.xml contains
> mappings, not bean definitions (mappings define
> many-to-many relationships
> between fields of several objects).
> I have of course the source for this mapper
> framework. If the decision was
> only mine I would be pleased to share it. I need to
> discuss this with other
> people within my company who should also be involved
> in this decision. I
> hope to get this sorted out this week...
>
> Are you still exploring solutions for a validation
> framework?
>
> Fr.
>
> -Original Message-
> From: David Winterfeldt
> [mailto:[EMAIL PROTECTED]]
> Sent: 15 June 2001 14:31
> To: [EMAIL PROTECTED]
> Subject: RE: Client/Server Side Validation for
> Struts 1.1
>
>
> I just wanted to put this out there to see what
> people
> think since I took the time to look at how Barracuda
> worked. I like the idea of not having two classes
> (ActionForm and a data bean), but I guess there will
> be a few different tools to autogenerate these as
> time
> goes by. Do you autogenerate classes based on the
> xml
> file? You have all the information in the xml file
> to
> make this possible, right? I think most of the
> issues
> you mention could be worked around, but you're
> Mapper
> idea is much more flexible. Is any source for what
> you've done available to look at or is it
> proprietary
> (I do have the xml file you sent to the list)?
>
> David
>
> --- Rey Francois <[EMAIL PROTECTED]> wrote:
> > David,
> >
> > A few remarks:
> > - I'm not sure that we should loose the value
> > entered by the user once the
> > transformation is done. Although I see the
> argument
> > that once transformed
> > the string value is most likely redundant, there
> may
> > be cases when it is
> > still useful. Also, unless you're able to make the
> > reverse transformation
> > and produce the exact same string as the user has
> > entered, further display
> > of the form may confuse a user when the displayed
> > fields differ from what he
> > has entered. I would be more in favor of an
> > ActionForm that is just a
> > placeholder for values entered by the user, like
> it
> > is at present.
> > - Having only one validator per property is a
> > limitation. We should be able
> > to have more than one like you already support in
> > your current framework. We
> > should also think about validation across several
> > fields. For example, in
> > the application we're working on we have a page
> > where a date is entered via
> > three different text fields. This introduces the
> > requirement to be able to
> > validate and transform multiple fields at a time.
> >
> > To satisfy this requirement we have now a 'Mapper'
> > framework to validate
> > and transform ActionForm properties. Mainly all we
> > do now is customizing a
> > configuration file which contains things like (at
> > the lower levels of the
> > hierarchy):
> >
> >
> >
> >
> >
> >
> >
> >
> > if (!isDay(source[0])) fail("Invalid day");
> > if (!isMonth(source[1])) fail("Invalid month");
> > if (!isYear(source[2])) fail("Invalid year");
> >
> >
> >
> >
> >
> >
> > Note that we ha
Can someone resend the file I sent this morning
For some reason I did not receive at work the file I sent this morning called struts_doc.html. Can someone repost it to the list or resend it to me. [EMAIL PROTECTED]
RE: Client/Server Side Validation for Struts 1.1
David,
We don't generate any classes yet, but the intention would be to do so for
ActionForms at a later stage.
We would use a separate XML file, because the mapper-config.xml contains
mappings, not bean definitions (mappings define many-to-many relationships
between fields of several objects).
I have of course the source for this mapper framework. If the decision was
only mine I would be pleased to share it. I need to discuss this with other
people within my company who should also be involved in this decision. I
hope to get this sorted out this week...
Are you still exploring solutions for a validation framework?
Fr.
-Original Message-
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 15 June 2001 14:31
To: [EMAIL PROTECTED]
Subject: RE: Client/Server Side Validation for Struts 1.1
I just wanted to put this out there to see what people
think since I took the time to look at how Barracuda
worked. I like the idea of not having two classes
(ActionForm and a data bean), but I guess there will
be a few different tools to autogenerate these as time
goes by. Do you autogenerate classes based on the xml
file? You have all the information in the xml file to
make this possible, right? I think most of the issues
you mention could be worked around, but you're Mapper
idea is much more flexible. Is any source for what
you've done available to look at or is it proprietary
(I do have the xml file you sent to the list)?
David
--- Rey Francois <[EMAIL PROTECTED]> wrote:
> David,
>
> A few remarks:
> - I'm not sure that we should loose the value
> entered by the user once the
> transformation is done. Although I see the argument
> that once transformed
> the string value is most likely redundant, there may
> be cases when it is
> still useful. Also, unless you're able to make the
> reverse transformation
> and produce the exact same string as the user has
> entered, further display
> of the form may confuse a user when the displayed
> fields differ from what he
> has entered. I would be more in favor of an
> ActionForm that is just a
> placeholder for values entered by the user, like it
> is at present.
> - Having only one validator per property is a
> limitation. We should be able
> to have more than one like you already support in
> your current framework. We
> should also think about validation across several
> fields. For example, in
> the application we're working on we have a page
> where a date is entered via
> three different text fields. This introduces the
> requirement to be able to
> validate and transform multiple fields at a time.
>
> To satisfy this requirement we have now a 'Mapper'
> framework to validate
> and transform ActionForm properties. Mainly all we
> do now is customizing a
> configuration file which contains things like (at
> the lower levels of the
> hierarchy):
>
>
>
>
>
>
>
>
> if (!isDay(source[0])) fail("Invalid day");
> if (!isMonth(source[1])) fail("Invalid month");
> if (!isYear(source[2])) fail("Invalid year");
>
>
>
>
>
>
> Note that we have separated the concept of
> validation and conversion. While
> multiple validators can be invoked on multiple
> fields at a time (using a
> small Java-like language), only one converter is
> invoked, possibly on
> multiple fields, like in the above example. The
> mapping shown above is a
> full one: it contains validation, conversion, and
> transfer (of the converted
> value to the destination). But nothing prevents you
> from defining mappings
> that only contains validation.
> Mappers are actually totally independent from
> Struts, so the framework can
> be applied in other types of application for
> validation and transformation.
> The integration with struts is just in two places:
> in a descendent from the
> ActionServlet, where we load the configuration file,
> and in a descendant
> from the ActionForm, where the validate method calls
> the mapper associated
> with the form and produces an ActionError for each
> validation/transformation
> failure.
>
> Fr.
>
> -Original Message-
> From: David Winterfeldt
> [mailto:[EMAIL PROTECTED]]
> Sent: 14 June 2001 06:32
> To: [EMAIL PROTECTED]
> Subject: Re: Client/Server Side Validation for
> Struts 1.1
>
>
> I just saw the type conversion thread going on in
> the
> user list, but I've thought about this for a bit and
> you mentioned possibly modeling or taking code from
> an
> existing framework.
>
> How closely have you looked at Barracuda Ted? Some
> of
> what they do is interesting. I think we could make
> an
> ActionForm derivitive that loosely followed their
> steps in processing an object.
>
> Barracuda
> -
> FormMap
>FormElement
> key - the key/property name
> type - the FormType (ie. String, Boolean,
> Integer, etc)
> defaultVal - the default value (ie. the value
> to
> be used if the key
Re: I would like to offer myself to help with documentation
On Mon, 18 Jun 2001, Jonathan Asbell wrote: > does someone have an example they can shoot to me of the xml and xsl used in > documentation. > All of the docs in the Struts Documentation application (which is also the contents of the Struts web site) are generated this way. In addition, the build process creates all of the Struts TLD files from the same XML input that the tag library reference docs are created from (so you only have to make one change when new tags or attributes are added). If you download the source distribution, and run the "dist" target, the docs will be built. The particular commands are in the "build-webapps.xml" script -- look for places where Ant's
Re: Documentation wish list repository
On Mon, 18 Jun 2001, Jonathan Asbell wrote: > Hi Craig. Could we put together a repository of the documentation wish list > items. It would be unreasonable for me to be searching through e-mails to > do this > Definitely. Adding a docs section to the TODO list for 1.1 seems like an appropriate means to accumulate these. If people want to fire away the ideas they've got so far, I'll add them to what Jonathan has already suggested and commit it. Craig > - Original Message - > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, June 16, 2001 5:12 PM > Subject: Re: I would like to offer myself to help with documentation > > > > > > > > On Sat, 16 Jun 2001, Jonathan wrote: > > > > > Hello all. > > > It seems that there is a back log of documentation to do and I would > like to > > > offer to help with it as I am very good at explaining things. It also > helps > > > me understand the framework in a deeper way. However, because I am > still > > > relatively green with Struts (3 months) I will need to correspond with > some > > > of you outside of the list to get questions answered (I dont want to > clutter > > > up the list with these questions). I can complete sections according to > > > when you want them, or I can do it in the order I want. > > > > > > > Sounds great! This is a good place to talk about what the docs should > > include. > > > > On my personal wish list: > > > > * High-quality UML diagrams covering all aspects of the architecture > > of Struts (especially sequence diagrams of how requests are handled). > > Anybody know some good+cheap tools for this purpose? > > > > * Tutorials (and example webapps) for a few common design idioms, such as > > a wizard-type multipage dialog. Although, maybe we ought to wait on > > this particular one if we're going to add pager-type tags. > > > > * Examples of extending the controller servlet to initialize your own > > application resources. > > > > * Examples that integrate some other commonly available tag libraries > > (such as those in jakarta-taglibs). However, I'm not personally a > > huge fan of using the DB tags, because it can encourage you to stray > > away from MVC :-). > > > > * Step-by-step how to construct a web app. Yes, this covers a lot of > > ground that is not Struts-specific, but this would clear up a lot of the > > complexity faced by new developers. A good starting point might be the > > "Application Developer's Guide" that ships with Tomcat (disclaimer: I > > wrote it, so don't be too hard on me :-). > > > > * Completed "package.html" files for the remaining packages (used as > > Developer's Guide links in the documentation). > > > > * A comprehensive example that uses Data Acess Objects to talk to a > > relational database. Ted's got some good starts here, but I'm thinking > > more about a "real" application -- perhaps something like the > > FAQ-O-MATIC idea, but written based on Struts? > > > > * A comprehensive example that uses EJBs to delegate business logic to > > session beans, and persistence logic to entity beans. Obviously not > > everyone will be able to run this, but you can at least look and see > > how such an app could be constructed. > > > > A couple of things to think about before we start writing docs that will > > be out of date quickly: > > > > * I'm planning to migrate to jakarta-commons versions of the shareable > > pieces of Struts that have migrated there, including: Bean Utils, > > Digester, DBCP (connection pool), Collections classes, and Message > > Resources. Docs are still welcome in all of these areas, but they > > should probably be done in jakarta-commons instead of here. > > > > * The JSP Standard Tag Library will have an early access version of their > > tags available in the near future. There will be some significant > > overlap with our tags in the struts-bean and struts-logic libraries, > > and an expression language for nested property access that will be > > similar to (but not identical) to ours. We'll want to think in the > > long run about making sure that Struts interoperates nicely with > > these tags. Because they will be standard, JSP page compilers will > > be able to generate optimized code for them. > > > > * A little further down the pike, the result of the JavaServer Faces > > (JSR-127) effort to create a standard GUI Component Model for web apps > > will be in early access. At that time, I'll want to build some app > > examples that use JSF as the user interface, but interact with the > > rest of the Struts framework. NOTE: I am on the expert group for > > JSR-127, so you can rest assured that the two technologies will play > > together nicely! > > > > > If this is ok with you all and you are interested, please send me an > email > > > at mailto:[EMAIL PROTECTED] > > > > > > Let us all salute the Sixers on their valiant effort last nigh
RE: Unsubscribe me...............
Title: Unsubscribe me... do it yourself dude -Original Message-From: Moses Lam [mailto:[EMAIL PROTECTED]]Sent: Monday, June 18, 2001 3:25 PMTo: '[EMAIL PROTECTED]'Subject: RE: Unsubscribe me... please unsubscribe me also. mo
RE: Unsubscribe me...............
Title: Unsubscribe me... please unsubscribe me also. mo
Unsubscribe me...............
Title: Unsubscribe me... Please unsubscribe me from this list. Sachin Mapara. Trigyn Technologies Ltd. Tel :- 518 86 86 (O) Ext.- 537 95251 - 44 10 39 (R)
Re: rough draft of initial documentation
I'm on my way to Altanta to do some Struts training today, and will take this with me to read on the plane. It may be Tuesday before I can post any comments (just don't think I'd forget you ;-). -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ > Jonathan Asbell wrote: > > pleas comment on this initial rough draft. There is no color yet. > > Name: new_struts_docs.htm >new_struts_docs.htmType: Hypertext Markup Language (text/html) > Encoding: quoted-printable
Re: I would like to offer myself to help with documentation
Absolutely everything is in the source download, under /doc Jonathan Asbell wrote: > > does someone have an example they can shoot to me of the xml and xsl used in > documentation.
SV: [ANNOUNCEMENT] Struts 1.0 (Final) Released
Woohooo got job devs!!! I'm in the process of putting a evelatuation of struts together, as I have recently completed my FIRST project implemented in struts... Nice!! -Oprindelig meddelelse- Fra: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sendt: 16 June 2001 02:23 Til: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Emne: [ANNOUNCEMENT] Struts 1.0 (Final) Released As promised at JavaOne, the Struts project team is proud to announce the availability of Version 1.0 (final release) of the Struts Framework. The binary distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/ and the source distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/ Craig McClanahan
