Re: Prakash Malani article on JavaWorld
Hi Sri, Yes, now it's workingapologized, forget to put the html taglib. : ( Thanks, Anen - Original Message - From: "Sri Sankaran" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, September 06, 2002 10:18 PM Subject: RE: Prakash Malani article on JavaWorld What do you mean "can not be displayed"? o Are you seeing an field but no data -- does your form bean have a getId (make sure of the case)? Does it have a non-blank value? o Are you not seeing an input field at all? -- What does the source of the html look like? I'm sure you have the html taglib specified in the jsp... Sri > -Original Message- > From: Anen Wu [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 05, 2002 10:53 PM > To: Struts Users Mailing List > Subject: Prakash Malani article on JavaWorld > > > Has any one have tried Prakash's article on JavaWorld related > integration of Struts and Tiles. > > I have tried the "Solution 6" (Integration of Struts and > tiles) , working fine. But when I tried to put some struts > tag inside one of the body, bBody.jsp, like below : > > > Text Box Here : > > > > b's body... > > > > the struts tag can not be displayed (rendered), any one can help pls > > > Rgds, > > anen > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: Prakash Malani article on JavaWorld
What do you mean "can not be displayed"? o Are you seeing an field but no data -- does your form bean have a getId (make sure of the case)? Does it have a non-blank value? o Are you not seeing an input field at all? -- What does the source of the html look like? I'm sure you have the html taglib specified in the jsp... Sri > -Original Message- > From: Anen Wu [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 05, 2002 10:53 PM > To: Struts Users Mailing List > Subject: Prakash Malani article on JavaWorld > > > Has any one have tried Prakash's article on JavaWorld related > integration of Struts and Tiles. > > I have tried the "Solution 6" (Integration of Struts and > tiles) , working fine. But when I tried to put some struts > tag inside one of the body, bBody.jsp, like below : > > > Text Box Here : > > > > b's body... > > > > the struts tag can not be displayed (rendered), any one can help pls > > > Rgds, > > anen > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Prakash Malani article on JavaWorld
Has any one have tried Prakash's article on JavaWorld related integration of Struts and Tiles. I have tried the "Solution 6" (Integration of Struts and tiles) , working fine. But when I tried to put some struts tag inside one of the body, bBody.jsp, like below : Text Box Here : b's body... the struts tag can not be displayed (rendered), any one can help pls Rgds, anen
Re: Article on JavaWorld
Haven't read it yet but the November issue of The Java Report has a struts article. Ted Husted wrote: [EMAIL PROTECTED]">On 12/4/2000 Jean-Baptiste Nizet wrote: This shows, once again, that Struts is more andmore used and recognized in the Java community.On 11/3/2000 Nikolaus Rumm wrote: but go to http://www.informit.com/, Programming/Java and look for Maneesh Sahu's article on struts. I checked the archive for "articles" and "powered" and came up with thereference to an InformIt article (that I couldn't find there). Anyone have other struts article or powered by references? -- Curtis R. Cooley [EMAIL PROTECTED]
Java Report Struts Article (was Re: Article on JavaWorld)
Ted Husted wrote: > Anyone have other struts article or powered by references? The November issue of Java Report has an article on Struts that focuses on Struts MVC. The article's code is a little out of date, due to all of the changes that have occurred since the article was written. david
RE: Article on JavaWorld
Just a Note: Open-source aside, making medications (patches) to code for work around in libraries, frameworks, even compilers and os, has always been part of software development. Maybe we should have a Struts offramp. - Malcolm > -Original Message- > From: Lacerda, Wellington (AFIS) [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 06, 2000 3:00 AM > To: '[EMAIL PROTECTED]' > Subject: RE: Article on JavaWorld > > > I agree 100% with you. I've had some bitter experiences with that myself > (and that's why I'm writing a book on tag libraries right now - AND Struts > !). But you must concede that, as in my case, there are > environments where > life is not made to be that easy. > > But you must to concede that, even with tag libraries life don't > become that > easier. Reuse is a tricky thing to acquire. You can't reuse too > much neither > too few. There are other risks with tags, while components, like component > super overloading (too few tags that make too MANY things) or component > superabundancy (too many of them doing ALMOST the same things). Or, as I > commented, what if the tags just aren't adequate ? > > What I was trying to say there is that the argument must be based > in all the > shades of gray, and there's no such thing as "THE TRUE POWER" of Struts in > rigid application models. As far as I'm concerned, I see the true power of > Struts in its ability to accommodate all those situations and still > providing a sound and elegant alternative for each case. It is that what > seduced me into the project. > > Regarding the article, I see it providing some interesting ideas for a > problem Struts has: excess of beans we have to code for LARGE > applications. > There's no technical argument to break the resistance against a BORING > procedure (culture ALWAYS breaks technique - we must remember that). I > provided once a tentative solution creating some tool (FBBuilder - form > beans builder) to try to figure the beans out automatically. > Didn't get much > response (I can understand that). This is another approach, > generalising the > bean concept. We will have to figure out something about that problem, and > this seems to be a good candidate. Regarding the idea of changing > BeanUtils, > ok, why not sub-classing it with an AutoBeanUtils class instead ? > > Wellington > > -Original Message----- > From: Dave Harms [mailto:[EMAIL PROTECTED]] > Sent: 06 December 2000 03:26 > To: [EMAIL PROTECTED]; Dave Harms > Subject:Re: Article on JavaWorld > > Wellington, > > > but...what if the company has only Java programmers as > > JSP designers ? Most of these arguments are based on > cultural more than > > technical reasons. > > There are still problems with, for example, scriptlets even > in a > situation like this. JSPs are not a particularly > code-friendly > environment. And re-use is more difficult. So I think even > if the Java > programmers are designing the pages, using scriptlets will > tend to make > life more difficult. I think these are sound technical > objections. > > Dave > > Dave Harms > [EMAIL PROTECTED]
RE: Article on JavaWorld
I agree 100% with you. I've had some bitter experiences with that myself (and that's why I'm writing a book on tag libraries right now - AND Struts !). But you must concede that, as in my case, there are environments where life is not made to be that easy. But you must to concede that, even with tag libraries life don't become that easier. Reuse is a tricky thing to acquire. You can't reuse too much neither too few. There are other risks with tags, while components, like component super overloading (too few tags that make too MANY things) or component superabundancy (too many of them doing ALMOST the same things). Or, as I commented, what if the tags just aren't adequate ? What I was trying to say there is that the argument must be based in all the shades of gray, and there's no such thing as "THE TRUE POWER" of Struts in rigid application models. As far as I'm concerned, I see the true power of Struts in its ability to accommodate all those situations and still providing a sound and elegant alternative for each case. It is that what seduced me into the project. Regarding the article, I see it providing some interesting ideas for a problem Struts has: excess of beans we have to code for LARGE applications. There's no technical argument to break the resistance against a BORING procedure (culture ALWAYS breaks technique - we must remember that). I provided once a tentative solution creating some tool (FBBuilder - form beans builder) to try to figure the beans out automatically. Didn't get much response (I can understand that). This is another approach, generalising the bean concept. We will have to figure out something about that problem, and this seems to be a good candidate. Regarding the idea of changing BeanUtils, ok, why not sub-classing it with an AutoBeanUtils class instead ? Wellington -Original Message- From: Dave Harms [mailto:[EMAIL PROTECTED]] Sent: 06 December 2000 03:26 To: [EMAIL PROTECTED]; Dave Harms Subject:Re: Article on JavaWorld Wellington, > but...what if the company has only Java programmers as > JSP designers ? Most of these arguments are based on cultural more than > technical reasons. There are still problems with, for example, scriptlets even in a situation like this. JSPs are not a particularly code-friendly environment. And re-use is more difficult. So I think even if the Java programmers are designing the pages, using scriptlets will tend to make life more difficult. I think these are sound technical objections. Dave Dave Harms [EMAIL PROTECTED]
Re: Article on JavaWorld
Thor, > Why should source code not be changed? What is the harm, within > a specific project, to change the source code to add functionality? How > would an open source project ever evolve if all experiments where banished? > Should there be a monopopy on making suggestions? I personally don't think that source code from a project like Struts should never be changed. However the risk in changing such code is that it makes upgrading to a later release more problematic. Now you have to merge your changes back in. As Craig suggests, it's better to propose the changes back to the project and hope for acceptance. Dave Dave Harms [EMAIL PROTECTED]
Re: Article on JavaWorld
Wellington, > but...what if the company has only Java programmers as > JSP designers ? Most of these arguments are based on cultural more than > technical reasons. There are still problems with, for example, scriptlets even in a situation like this. JSPs are not a particularly code-friendly environment. And re-use is more difficult. So I think even if the Java programmers are designing the pages, using scriptlets will tend to make life more difficult. I think these are sound technical objections. Dave Dave Harms [EMAIL PROTECTED]
Re: Article on JavaWorld
If you're prepared to be patient, I need both of these, and can work on them but I won't be able to start unitl January on the development of it. The AutoBean idea (as an idea) is something I use already in Cold Fusion, and have done before in PL/SQL. The client side validator, as I posted before I have a good JavaScript validation library I can use, and am happy for it to be included. "Craig R. McClanahan" wrote: > The "AutoBean" concept has been requested several times, often in the guise of > "beans with dynamic properties" so that you don't have to create a form bean > with individual getters and setters. I'd like to explore this concept in depth > in Struts 1.1, which will give us time to make sure that a complete and coherent > set of support for such beans can be included (for example, all the custom tags > that know how to extract bean properties should now how to extract them from an > AutoBean, without the page developer having to do anything). > > The "Validator" concept is interesting. Besides the server-side format checking > that is being done here, I would also like to see the option for the form tags > to generate client-side JavaScript code (if requested) to check as many things > like this as you can on the client side, to improve the user experience.
Re: Article on JavaWorld
Ted Husted wrote: > > More to the point, do you have any thoughts about his AutoBean or > Validator interfaces? > The "AutoBean" concept has been requested several times, often in the guise of "beans with dynamic properties" so that you don't have to create a form bean with individual getters and setters. I'd like to explore this concept in depth in Struts 1.1, which will give us time to make sure that a complete and coherent set of support for such beans can be included (for example, all the custom tags that know how to extract bean properties should now how to extract them from an AutoBean, without the page developer having to do anything). The "Validator" concept is interesting. Besides the server-side format checking that is being done here, I would also like to see the option for the form tags to generate client-side JavaScript code (if requested) to check as many things like this as you can on the client side, to improve the user experience. > > -T. Craig
Re[4]: Article on JavaWorld
Hello Ted,
Tuesday, December 05, 2000, 5:59:58 PM, you wrote:
TH> Do you think Thor's Validation code could be extended to use the
TH> standard i18n mechanism for number and date formatting, but regex for
TH> others?
I found this mechanism not ideal... More useful can be model where
fields and validation rules for it defined in config file for struts
not directly in classes or in jsp pages.
There we can define separate field sections or incorporate it to the
form sections. With each field section we can define all data needed
to to validate input values.
Now I use import/export methods in form beans to converse data to/from
String values.
public void importEntity( EntityBean value,
HttpServletRequest request, ActionErrors errors )
throws ServletException {}
public EntityBean exportEntity( EntityBean value,
HttpServletRequest request, ActionErrors errors )
throws ServletException {}
For each time bean with data used as source to populate
form fields (with i18n support) and at save moment export method is
called to populate bean with data from form bean. All conversion
errors this mechanism stores in standart errors container. This is not
ideal. Problem is hard coded conversions. Each conversion is some
strings of code, where DateFormat or NumberFormat classes are used to
import/export values. I think that all conversion logic can be
incorporated to BeanUtils and instead of separate set/get callings
populate method with automatic values conversions on i18n basis can be
used. All rules for this conversions can be stored in struts config
file and retrieved by the digester. For example, some fields of form
are defined in struts config file and all conversions with it can be
performed by BeanUtils in automatic mode. Some count of fields has
set/get methods too, but are not defined in struts config - this
fields would be populated in old manner and can be Strings only. But
all it is a raw idea...
But there are already exists some such solutions in my pocket.. 8) One
of them - bean:format tag, which derived from bean:write tag to
support properties printing with i18n support. Number, date, time
values can be printed with it. For special cases I can specify special
format and print values in special manner. I glad to pass it to the
community.
--
Best regards,
Olegmailto:[EMAIL PROTECTED]
RE: Article on JavaWorld
On Tue, 5 Dec 2000, Ted Husted wrote: > And, thanks again for publishing the Java World article. Every open > source projects suffers from a lack of working examples, and I hope you > will publish more on Struts in the future. There's no replacement for > real working code. +1
RE: Article on JavaWorld
> I can't see though how focusing on the tag libraries is harmful. I think this is a good point, Thor. After all, the Web site does take the trouble to indicate what you need to download just use the tag library on its own. And as others have pointed out, the real power of Struts is it's flexibility. Any good Java project is component based, and you should be able to choose the components you want to use, and replace the ones you don't. I'm finishing the specification of what will be my first Struts application this week. When I get to the hard code, I will be looking closely at your validation interface, and comparing it to the one outlined by Jean-Baptist, and the other ideas that have come up on the list. If I come up with a refinement, I'll be sure to let you know, in case there is ever an expanded edtion of your article. And, thanks again for publishing the Java World article. Every open source projects suffers from a lack of working examples, and I hope you will publish more on Struts in the future. There's no replacement for real working code. Meanwhile, if anyone has any links to other Struts articles, or Powered by Struts sites, I'd be very interested to see them. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
Re: Re[2]: Article on JavaWorld
> But all it about number and date formatting only. Regexp validations > useful for such validations as phone numbers, e-mails, etc. So it is > good addition to the struts for my mind. In general, yes, but beware the trap of trying to validate email with regex's, unless you have a very finite, specific domain of email addresses you're trying to validate (such as addresses from a given company). Regex's simply cannot handle the entire domain of the email address space.
RE: Article on JavaWorld
What is "the full power of Struts" ?
I was misled to believe it was flexibility !
I remember seen in this list few months ago some messages about Struts being
VERY flexible in terms of usage scenarios. I can use just the MVC main
process and forget about the tag libraries.
One can use just the i18n mechanism and implement out all the other stuff.
Or the forms.
Here where I work, Struts i18n mechanism would be happily ignored, just
because we have our own stuff. STILL it's MVC nucleus is very fine and the
validation stuff...hmm... there's this problem too: we do prefer don't use
the massive number of beans real big sites will demand from Struts.
Who cares if you use scriptlets ? I also believe using tags massively will
reduce the complexity of a page, will enable massive reuse, a very fine
separation of roles, but...what if the company has only Java programmers as
JSP designers ? Most of these arguments are based on cultural more than
technical reasons. If a company has a culture devoted to light design more
than programming, maybe one would like to use tags to encapsulate.
Otherwise, if the environment is made of JSP freaks that use HTML mock-ups
to build applications upon, the aim would be reuse. Otherwise, if the
environment is made of Servlet freaks, who will care about JSP ???
Maybe, being a first article on Struts, it could pass a personal view more
than an "institutional", so ?
Wellington
-Original Message-
From: Jean-Baptiste Nizet
[mailto:[EMAIL PROTECTED]]
Sent: 05 December 2000 15:09
To: [EMAIL PROTECTED]
Subject:Re: Article on JavaWorld
Thor Kristmundsson wrote:
> It would have been a good idea to ask this list first.
Unfortunatly I didn't
> know the list existed until a few days ago. A few weeks
back I looked for
> contact information on the Struts website and found an
email address
> reserved for "the press".
If you had looked with a little more attention, you would
have found the various
Struts mailing lists at the bottom of the Struts home page.
It always impresses
me how technical "gurus", writing in the press about
technical products, don't
even evaluate them in details.
> I sent an email to this address asking for a phone
> number of someone to talk to about the article but got no
response. It even
> occured to me that the project might be dead. I agree that
the whole of
> Struts deserves attention. Not just the tag libraries. And
I'm glad to hear
> that books and articles are on their way to cover the
whole. I can't see
> though how focusing on the tag libraries is harmful.
It's harmful because you ignore the full power of the
framework and thus
reinvent the wheel. For example, Struts has a wonderful
validation mechanism,
but, unfortunately, lacks some tags for displaying the
validation errors in an
elegant way to the end user (the errors tag is not
sufficient, IMHO). You
focused on the tag library, saw that these tags were
lacking, and thus
reimplemented the whole validation mechanism. On the other
hand, I know what
Struts is able to do in terms of validation and thus just
implemented two
additional tags for displaying them in a more elegant way
(See below for
details, if you're interested).
>
> Thor Kristmundsson
>
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Dienstag, 5. Dezember 2000 12:41
> To: Struts List
> Subject: RE: Article on JavaWorld
>
> On 12/4/2000 at 4:49 PM [EMAIL PROTECTED]
wrote:
> > As Jean-Baptiste said, surely the right way to do it is
to add or
> extend classes?
>
> Developers in the open source community have always
patched code to
> meet specific requirements. A prime argument for open
source is the
> ability to choose between patching and extending.
Obviously, developers
> who patch take the responsbility for applying the patch
again later.
I agree completely with all this, but I think that
1. Extending should be preferred to patching when possible
2. A product should not be patched if it already has the
functionality provided
Re: Article on JavaWorld
Thor Kristmundsson wrote: > It would have been a good idea to ask this list first. Unfortunatly I didn't > know the list existed until a few days ago. A few weeks back I looked for > contact information on the Struts website and found an email address > reserved for "the press". If you had looked with a little more attention, you would have found the various Struts mailing lists at the bottom of the Struts home page. It always impresses me how technical "gurus", writing in the press about technical products, don't even evaluate them in details. > I sent an email to this address asking for a phone > number of someone to talk to about the article but got no response. It even > occured to me that the project might be dead. I agree that the whole of > Struts deserves attention. Not just the tag libraries. And I'm glad to hear > that books and articles are on their way to cover the whole. I can't see > though how focusing on the tag libraries is harmful. It's harmful because you ignore the full power of the framework and thus reinvent the wheel. For example, Struts has a wonderful validation mechanism, but, unfortunately, lacks some tags for displaying the validation errors in an elegant way to the end user (the errors tag is not sufficient, IMHO). You focused on the tag library, saw that these tags were lacking, and thus reimplemented the whole validation mechanism. On the other hand, I know what Struts is able to do in terms of validation and thus just implemented two additional tags for displaying them in a more elegant way (See below for details, if you're interested). > > Thor Kristmundsson > > -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Dienstag, 5. Dezember 2000 12:41 > To: Struts List > Subject: RE: Article on JavaWorld > > On 12/4/2000 at 4:49 PM [EMAIL PROTECTED] wrote: > > As Jean-Baptiste said, surely the right way to do it is to add or > extend classes? > > Developers in the open source community have always patched code to > meet specific requirements. A prime argument for open source is the > ability to choose between patching and extending. Obviously, developers > who patch take the responsbility for applying the patch again later. I agree completely with all this, but I think that 1. Extending should be preferred to patching when possible 2. A product should not be patched if it already has the functionality provided by the patch (ex: validation) > > And, of course, Thor could have posted questions about his patch to the > list first. But now that the article is published < > http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html >, > lets ask the questions: > > "How could Struts accomplish the same result without a patch?" > > and/or > > "Should these patches be added to Struts?" > > If alternates turn up, they could be posted somewhere as an addendum to > the article. (Or, in a followup article?) It might also be nice to see > another addendum that addressed the shortcomings Craig mentioned < > http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg00891.ht > ml >. > > But, let's see some code, guys. > Here's the doc of two tags I wrote to handle validation errors. They allow to display a message, or an image, or anything else, just next to the field the error is associated with, by leveraging the Struts validation mechanism. Te code of these tags is trivial. I leave it as an exercise for the reader to implement them ;-) ifErrorExists - tests if a specific error exists, for a specific property Executes its body if a specific error is found. If name is not specified, the tag checks if one or more errors exist for the specified property. If name is specified, then the tag checks that the specific error exists for the specified property. If not specified, the property defaults to the "global" property, i.e., the tag searches for global errors, not associated with any property. Attribute Description Should be omitted in most cases. Name of the request scope bean errorsName under which a String[] object has possibly been stored. [The value of the org.apache.struts.Action.ERROR_KEY constant string]. name Name of the specific error to test. property Name of the property the error is associated with. ifErrorMissing - tests if a specific error exists Executes its body if a specific error is not found.If name is not specified, the tag checks if one or more errors exist for the specified property. If name is specified, then the tag checks that the specific error exists for the specified property. If not specified, the property defaults to the "global" property, i.e., the tag searches for global errors, not
Re: Re[2]: Article on JavaWorld
On 12/5/2000 at 3:34 PM Oleg V Alexeev wrote: >Java already has i18n mechanism and it can be used to format/parse output/input values in form processing. > But all it about number and date formatting only. Regexp validations useful for such validations as phone numbers, e-mails, etc. So it is good addition to the struts for my mind. Thanks, Oleg. Do you think Thor's Validation code could be extended to use the standard i18n mechanism for number and date formatting, but regex for others? -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
RE: Article on JavaWorld
It would have been a good idea to ask this list first. Unfortunatly I didn't know the list existed until a few days ago. A few weeks back I looked for contact information on the Struts website and found an email address reserved for "the press". I sent an email to this address asking for a phone number of someone to talk to about the article but got no response. It even occured to me that the project might be dead. I agree that the whole of Struts deserves attention. Not just the tag libraries. And I'm glad to hear that books and articles are on their way to cover the whole. I can't see though how focusing on the tag libraries is harmful. Thor Kristmundsson -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 5. Dezember 2000 12:41 To: Struts List Subject: RE: Article on JavaWorld On 12/4/2000 at 4:49 PM [EMAIL PROTECTED] wrote: > As Jean-Baptiste said, surely the right way to do it is to add or extend classes? Developers in the open source community have always patched code to meet specific requirements. A prime argument for open source is the ability to choose between patching and extending. Obviously, developers who patch take the responsbility for applying the patch again later. And, of course, Thor could have posted questions about his patch to the list first. But now that the article is published < http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html >, lets ask the questions: "How could Struts accomplish the same result without a patch?" and/or "Should these patches be added to Struts?" If alternates turn up, they could be posted somewhere as an addendum to the article. (Or, in a followup article?) It might also be nice to see another addendum that addressed the shortcomings Craig mentioned < http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg00891.ht ml >. But, let's see some code, guys. Personally, I think Thor's interfaces seem useful, and I may add his patches to my own code base. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
Re[2]: Article on JavaWorld
Hello Ted, Tuesday, December 05, 2000, 2:41:08 PM, you wrote: .. TH> Personally, I think Thor's interfaces seem useful, and I may add his TH> patches to my own code base. I think regexp validation is interesting and will be very useful.. But there are some problems with such kind of validation code - it uses hard rules to process number and date values. Java already has i18n mechanism and it can be used to format/parse output/input values in form processing. With it you can specify format strings too and make data formatting more flexible without regexp strings. But all it about number and date formatting only. Regexp validations useful for such validations as phone numbers, e-mails, etc. So it is good addition to the struts for my mind. -- Best regards, Olegmailto:[EMAIL PROTECTED]
RE: Article on JavaWorld
On 12/4/2000 at 4:49 PM [EMAIL PROTECTED] wrote: > As Jean-Baptiste said, surely the right way to do it is to add or extend classes? Developers in the open source community have always patched code to meet specific requirements. A prime argument for open source is the ability to choose between patching and extending. Obviously, developers who patch take the responsbility for applying the patch again later. And, of course, Thor could have posted questions about his patch to the list first. But now that the article is published < http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html >, lets ask the questions: "How could Struts accomplish the same result without a patch?" and/or "Should these patches be added to Struts?" If alternates turn up, they could be posted somewhere as an addendum to the article. (Or, in a followup article?) It might also be nice to see another addendum that addressed the shortcomings Craig mentioned < http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg00891.ht ml >. But, let's see some code, guys. Personally, I think Thor's interfaces seem useful, and I may add his patches to my own code base. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
RE: Article on JavaWorld
If users make changes to the Struts code then they won't be able to use the next release of Struts without re-implementing their changes in the new source. As Jean-Baptiste said, surely the right way to do it is to add or extend classes? Of course, getting your changes added to the Struts codebase itself is a different matter... ;-) Phil. -Original Message- From: Thor Kristmundsson [mailto:[EMAIL PROTECTED]] Sent: 04 December 2000 15:02 To: [EMAIL PROTECTED] Subject: RE: Article on JavaWorld You have a point, the article doens't make use of all of Struts feature. I was simply trying to convey the experience I got during a recent project of using the Struts JSP tag libraries. This project didn't lend itself to using the rest of Struts so I had nothing to report there. IMHO the methods presented do add value to Struts and could perhaps be incorporated. I cant see anything inherently wrong with changing the Struts code to accomodate these features. Thor Kristmundsson -Original Message- From: Jean-Baptiste Nizet [mailto:[EMAIL PROTECTED]] Sent: Montag, 4. Dezember 2000 16:06 To: [EMAIL PROTECTED] Subject: Article on JavaWorld Hi all, I just noticed that there is an article talking about Struts on JavaWorld, at http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html, written by Thor Kristmundsson, from ATG. This shows, once again, that Struts is more and more used and recognized in the Java community. Unfortunately, the article, IMHO, shows exactly what should NOT be done with Struts. The MVC pattern is broken (no real form bean, controller code in the JSP page, direct forwards to JSP pages, ...), the validation process of Struts is bypassed and re-invented, the error management is also re-invented, and this is done by modifying the Struts sources, instead of trying to enhancing it by adding or extending classes. What do you all think about it? I personnally think that someone knowing Struts perfectly (Craig, are you here?), should react to this article and show how all this could be done using Struts in a smart way, and explain what the real Struts is able to do. JB. -- Jean-Baptiste Nizet [EMAIL PROTECTED] R&D Engineer, S1 Belgium Kleine Kloosterstraat, 23 B-1932 Sint-Stevens Woluwe +32 2 200 45 42 This email and any files transmitted with it are intended solely for the addressee(s) and may be legally privileged and/or confidential. If you have received this email in error please destroy it and contact the sender, via our switchboard on +44 (0)20 7623 8000 or via return e-mail. You should not copy, forward or use the contents, attachments or information in any way. Any unauthorised use or disclosure may be unlawful. Dresdner Kleinwort Benson gives no warranty as to the accuracy or completeness of this email after it is sent over the Internet and accepts no responsibility for changes made after it was sent. Any opinion expressed in this email may be personal to the author and may not necessarily reflect the opinions of the Bank or its affiliates. They may also be subject to change without notice.
Re: Article on JavaWorld
On 12/4/2000 at 5:30 PM Craig R. McClanahan wrote: > I do have a problem with the way the example is coded -- it utilizes two techniques (posting back to the same JSP page, and embedding functional logic as scriptlets rather than custom tags) that are really not in the spirit of what Struts tries to do. In fairness to Thor, he stated more than once that this approach is not recommended, and was just used for brevity. More to the point, do you have any thoughts about his AutoBean or Validator interfaces? -T.
Re: Article on JavaWorld
Jean-Baptiste Nizet wrote: > Hi all, > > I just noticed that there is an article talking about Struts on JavaWorld, at > http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html, written by > Thor Kristmundsson, from ATG. This shows, once again, that Struts is more and > more used and recognized in the Java community. > Unfortunately, the article, IMHO, shows exactly what should NOT be done with > Struts. The MVC pattern is broken (no real form bean, controller code in the JSP > page, direct forwards to JSP pages, ...), the validation process of Struts is > bypassed and re-invented, the error management is also re-invented, and this is > done by modifying the Struts sources, instead of trying to enhancing it by > adding or extending classes. > > What do you all think about it? > > I personnally think that someone knowing Struts perfectly (Craig, are you > here?), should react to this article and show how all this could be done using > Struts in a smart way, and explain what the real Struts is able to do. > > JB. I don't have a particular problem with the idea of someone taking a package and customizing it. This is, after all, an open source project. (It would be nice, however, if changes and enhancements were proposed back to the community :-). I do have a problem with the way the example is coded -- it utilizes two techniques (posting back to the same JSP page, and embedding functional logic as scriptlets rather than custom tags) that are really not in the spirit of what Struts tries to do. I am aware of several article and book projects in the works that will deal with Struts. All of the ones I know about plan to cover the "Struts story" in a way that is more philosophically aligned with the application architecture that Struts enables (which this article, as is stated at the beginning, doesn't really utilize). As Thor can undoubtedly tell you, writing a good article is a time consuming exercize. I think that the Struts community might feel like lynching me if I started writing articles about Struts before getting 1.0 done :-). After that, we'll see ... Craig
RE: Article on JavaWorld
On 12/4/2000 at 2:50 PM Kevin Wang wrote: > I did something similar in our project to handle "extended properties", which include "automatic properties" as a special case when not a single property (and methods) is defined in the ActionForm bean. I tried extend Struts as much as possible and had to only change BeanUtils in a similar fashion. Details at http://archive.covalent.net/jakarta/struts-user/2000/11/0516.xml For another suggested change to UtilBean regarding it's handing of properties, see also < http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00380.html > Personally, I think Thor's interfaces < http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html > are very elegant patches, and demonstrate why open source is so important. We extend when we can, and patch when we can't (and then hope the package accepts our patch later). Any discussion on Thor's use of server-side regular expressions for validation? Does it contribute to some of the ideas covered in the recent "When do we validate" thread. < http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00765.html > -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
RE: Re[2]: Article on JavaWorld
Hi Oleg Thanks for sharing your thoughts on this. How do you support the point you are making? Why should source code not be changed? What is the harm, within a specific project, to change the source code to add functionality? How would an open source project ever evolve if all experiments where banished? Should there be a monopopy on making suggestions? Regards Thor -Original Message- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: Montag, 4. Dezember 2000 19:41 To: Thor Kristmundsson Subject: Re[2]: Article on JavaWorld Hello Thor, It is wrong solution, for my mind, to rewrite source instead of extend struts classes to incorporate your own functionality. Of course, you CAN do it, but it is wrong. I speak about tags not about BeanUtils class - all tag classes can extended to implement additional functionality (thanks to Craig - final keyword removed.. 8))) ) Monday, December 04, 2000, 6:01:32 PM, you wrote: TK> You have a point, the article doens't make use of all of Struts feature. I TK> was simply trying to convey the experience I got during a recent project of TK> using the Struts JSP tag libraries. This project didn't lend itself to using TK> the rest of Struts so I had nothing to report there. IMHO the methods TK> presented do add value to Struts and could perhaps be incorporated. I cant TK> see anything inherently wrong with changing the Struts code to accomodate TK> these features. TK> Thor Kristmundsson -- Best regards, Olegmailto:[EMAIL PROTECTED]
RE: Article on JavaWorld
I did something similar in our project to handle "extended properties", which include "automatic properties" as a special case when not a single property (and methods) is defined in the ActionForm bean. I tried extend Struts as much as posible and had to only change BeanUtils in a similar fashion. Details at http://archive.covalent.net/jakarta/struts-user/2000/11/0516.xml Kevin Wang -Original Message- From: Thor Kristmundsson [mailto:[EMAIL PROTECTED]] Sent: Monday, December 04, 2000 9:02 AM To: [EMAIL PROTECTED] Subject: RE: Article on JavaWorld You have a point, the article doens't make use of all of Struts feature. I was simply trying to convey the experience I got during a recent project of using the Struts JSP tag libraries. This project didn't lend itself to using the rest of Struts so I had nothing to report there. IMHO the methods presented do add value to Struts and could perhaps be incorporated. I cant see anything inherently wrong with changing the Struts code to accomodate these features. Thor Kristmundsson -Original Message- From: Jean-Baptiste Nizet [mailto:[EMAIL PROTECTED]] Sent: Montag, 4. Dezember 2000 16:06 To: [EMAIL PROTECTED] Subject: Article on JavaWorld Hi all, I just noticed that there is an article talking about Struts on JavaWorld, at http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html, written by Thor Kristmundsson, from ATG. This shows, once again, that Struts is more and more used and recognized in the Java community. Unfortunately, the article, IMHO, shows exactly what should NOT be done with Struts. The MVC pattern is broken (no real form bean, controller code in the JSP page, direct forwards to JSP pages, ...), the validation process of Struts is bypassed and re-invented, the error management is also re-invented, and this is done by modifying the Struts sources, instead of trying to enhancing it by adding or extending classes. What do you all think about it? I personnally think that someone knowing Struts perfectly (Craig, are you here?), should react to this article and show how all this could be done using Struts in a smart way, and explain what the real Struts is able to do. JB. -- Jean-Baptiste Nizet [EMAIL PROTECTED] R&D Engineer, S1 Belgium Kleine Kloosterstraat, 23 B-1932 Sint-Stevens Woluwe +32 2 200 45 42
Re: Re[2]: Article on JavaWorld
> It is wrong solution, for my mind, to rewrite source instead of extend > struts classes to incorporate your own functionality. Of course, you > CAN do it, but it is wrong. I speak about tags not about BeanUtils > class - all tag classes can extended to implement additional > functionality (thanks to Craig - final keyword removed.. 8))) ) Though I am a very, very inexperience Struts user, I tend to agree here. Another reason for me at least, since there is an incredible dearth of documentation on this framework, any and all new info that is written about it should be "100% Struts Compliant" so as to run out of the box. This will cause the least confusion for the end user.
Re[2]: Article on JavaWorld
Hello Thor, It is wrong solution, for my mind, to rewrite source instead of extend struts classes to incorporate your own functionality. Of course, you CAN do it, but it is wrong. I speak about tags not about BeanUtils class - all tag classes can extended to implement additional functionality (thanks to Craig - final keyword removed.. 8))) ) Monday, December 04, 2000, 6:01:32 PM, you wrote: TK> You have a point, the article doens't make use of all of Struts feature. I TK> was simply trying to convey the experience I got during a recent project of TK> using the Struts JSP tag libraries. This project didn't lend itself to using TK> the rest of Struts so I had nothing to report there. IMHO the methods TK> presented do add value to Struts and could perhaps be incorporated. I cant TK> see anything inherently wrong with changing the Struts code to accomodate TK> these features. TK> Thor Kristmundsson -- Best regards, Olegmailto:[EMAIL PROTECTED]
Re: Article on JavaWorld
On 12/4/2000 Jean-Baptiste Nizet wrote: > This shows, once again, that Struts is more andmore used and recognized in the Java community. On 11/3/2000 Nikolaus Rumm wrote: > but go to http://www.informit.com/, Programming/Java and look for Maneesh Sahu's article on struts. I checked the archive for "articles" and "powered" and came up with the reference to an InformIt article (that I couldn't find there). Anyone have other struts article or powered by references?
RE: Article on JavaWorld
You have a point, the article doens't make use of all of Struts feature. I was simply trying to convey the experience I got during a recent project of using the Struts JSP tag libraries. This project didn't lend itself to using the rest of Struts so I had nothing to report there. IMHO the methods presented do add value to Struts and could perhaps be incorporated. I cant see anything inherently wrong with changing the Struts code to accomodate these features. Thor Kristmundsson -Original Message- From: Jean-Baptiste Nizet [mailto:[EMAIL PROTECTED]] Sent: Montag, 4. Dezember 2000 16:06 To: [EMAIL PROTECTED] Subject: Article on JavaWorld Hi all, I just noticed that there is an article talking about Struts on JavaWorld, at http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html, written by Thor Kristmundsson, from ATG. This shows, once again, that Struts is more and more used and recognized in the Java community. Unfortunately, the article, IMHO, shows exactly what should NOT be done with Struts. The MVC pattern is broken (no real form bean, controller code in the JSP page, direct forwards to JSP pages, ...), the validation process of Struts is bypassed and re-invented, the error management is also re-invented, and this is done by modifying the Struts sources, instead of trying to enhancing it by adding or extending classes. What do you all think about it? I personnally think that someone knowing Struts perfectly (Craig, are you here?), should react to this article and show how all this could be done using Struts in a smart way, and explain what the real Struts is able to do. JB. -- Jean-Baptiste Nizet [EMAIL PROTECTED] R&D Engineer, S1 Belgium Kleine Kloosterstraat, 23 B-1932 Sint-Stevens Woluwe +32 2 200 45 42
Article on JavaWorld
Hi all, I just noticed that there is an article talking about Struts on JavaWorld, at http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html, written by Thor Kristmundsson, from ATG. This shows, once again, that Struts is more and more used and recognized in the Java community. Unfortunately, the article, IMHO, shows exactly what should NOT be done with Struts. The MVC pattern is broken (no real form bean, controller code in the JSP page, direct forwards to JSP pages, ...), the validation process of Struts is bypassed and re-invented, the error management is also re-invented, and this is done by modifying the Struts sources, instead of trying to enhancing it by adding or extending classes. What do you all think about it? I personnally think that someone knowing Struts perfectly (Craig, are you here?), should react to this article and show how all this could be done using Struts in a smart way, and explain what the real Struts is able to do. JB. -- Jean-Baptiste Nizet [EMAIL PROTECTED] R&D Engineer, S1 Belgium Kleine Kloosterstraat, 23 B-1932 Sint-Stevens Woluwe +32 2 200 45 42
