RE: Justifying Struts
For a simple and small project it really doesn't matter whether you implement model 1 or 2 or any kind of framework. But when it comes to large projects and complexities, a more clean structured model is always desired. It all accounts when maintaining the whole application. Whether its a Java Bean, EJB, or a JSP, I prefer to write it clean, small and simple logics, in a clean, simple and small source file. I moved from a model 1 arch to model 2 and now to struts, I could definitely see the importance of all the elements in the framework, whether its a layout tiles, validator or taglibs. For larger and complex projects, definitely struts framework is WORTH, pays off in developing and maintaining. All I can say is its CLEAN and SIMPLE thats what we strive for in life as well. Panchasheel -Original Message- From: Mike Jasnowski [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:38 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: Justifying Struts Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? Have you looked at DynaForms? 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. I think in some cases though, validation constraints are complex enough they cannot all be done through simple means. Once you start adding on layers of complexity, without a good pattern to follow, you may get each developer doing it slightly differently. -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 5:38 AM To: Struts Users Mailing List Subject: RE: Justifying Struts Maybe he should also drop java and the servlet api while he is at it - after all you can do all of that stuff in assembly code. How hard is it to implement a web server? - just listen on the port, send some text back and forth. Piece of cake. Run a lot faster too without all that unneccesary overhead the jvm imposes. snip application developers, who are basically scripters (not OO developers) /snip Oh we are just scripters are we? I suppose its true - real programmers write straight to the metal - none of this high level language stuff... design patterns are for quiche eaters... http://www.pbm.com/~lindahl/real.programmers.html http://www.psych.usyd.edu.au/pdp-11/rp.html Ok thats probably enough since its still only Thursday... ;- -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 17:10 To: Struts Users Mailing List Subject: Re: Justifying Struts I'm sorry man, you're reservations are mostly wrong. one thing you have to bare in mind is that we're not all as clever as you, in fact i'd argue that I'm very stupid and many people are as equally stupid. If you've managed to maintain an MVC pattern using model 1 techniques what are you doing researching struts? Model 1 techniques were also attempts to encourage MVC but html'ists who are keen to overcome their programmer envy would break the pattern, if you don't have this problem and your current development practices don't break this pattern you don't need struts then do you? I'm interested in how many times oh that's easy is said in your team, how much unaccounted time pops up on your projects especially when completing easy tasks. taglibs have value in the real world and the struts taglibs more so, the overhead isn't that great and are far less than the cognitive overheads that some ropey scriptlet writing can cause. while i understand your preference for scriptlets, putting your team forward as the sole inhabitance of the real world sounds a little incongruous with the model 1 utopia that you're all living in. Anyway there are numerous threads like yours on this group that have been posted over the last few weeks. take a read. i'd argue that your position requires justification not struts. cheers mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers
RE: Justifying Struts
I must speak up here. I would be so bold as to say that Struts is important to use on all level of sites. I have developed sites in Perl, ASP (not .NET), PHP and I would have to say they all lack in comparison to J2EE/Struts. Most of my sites are small non-enterprise level apps. But, there are still ample organizational needs and maintainability issues that are addressed through the use of Struts. If it requires dynamic interaction then Struts is worth the time learning an applying to any project. The most important thing to remember is REUSE. The Struts framework is the Model2 portion that is reusable. The next step is to take Struts throw in a few useful APIS and a few other complementary frameworks and you have yourself a reusable environment that can span across several project. I have successfully been able to create reusable modules that are the same across several sites. This is a major time savings and it makes me profitable. A little work up front pays off later. Brandon Goodin -Original Message- From: Gandle, Panchasheel [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 6:59 AM To: 'Struts Users Mailing List' Subject: RE: Justifying Struts For a simple and small project it really doesn't matter whether you implement model 1 or 2 or any kind of framework. But when it comes to large projects and complexities, a more clean structured model is always desired. It all accounts when maintaining the whole application. Whether its a Java Bean, EJB, or a JSP, I prefer to write it clean, small and simple logics, in a clean, simple and small source file. I moved from a model 1 arch to model 2 and now to struts, I could definitely see the importance of all the elements in the framework, whether its a layout tiles, validator or taglibs. For larger and complex projects, definitely struts framework is WORTH, pays off in developing and maintaining. All I can say is its CLEAN and SIMPLE thats what we strive for in life as well. Panchasheel -Original Message- From: Mike Jasnowski [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:38 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: Justifying Struts Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? Have you looked at DynaForms? 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. I think in some cases though, validation constraints are complex enough they cannot all be done through simple means. Once you start adding on layers of complexity, without a good pattern to follow, you may get each developer doing it slightly differently. -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 5:38 AM To: Struts Users Mailing List Subject: RE: Justifying Struts Maybe he should also drop java and the servlet api while he is at it - after all you can do all of that stuff in assembly code. How hard is it to implement a web server? - just listen on the port, send some text back and forth. Piece of cake. Run a lot faster too without all that unneccesary overhead the jvm imposes. snip application developers, who are basically scripters (not OO developers) /snip Oh we are just scripters are we? I suppose its true - real programmers write straight to the metal - none of this high level language stuff... design patterns are for quiche eaters... http://www.pbm.com/~lindahl/real.programmers.html http://www.psych.usyd.edu.au/pdp-11/rp.html Ok thats probably enough since its still only Thursday... ;- -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 17:10 To: Struts Users Mailing List Subject: Re: Justifying Struts I'm sorry man, you're reservations are mostly wrong. one thing you have to bare in mind is that we're not all as clever as you, in fact i'd argue that I'm very stupid and many people are as equally stupid. If you've managed to maintain an MVC pattern using model 1 techniques what are you doing researching struts? Model 1 techniques were also attempts to encourage MVC but html'ists who are keen to overcome their programmer envy would break the pattern, if you don't have this problem and your current development practices don't break this pattern you don't need struts then do you? I'm interested in how many times oh that's easy is said in your team, how much unaccounted time pops up on your projects especially when completing easy tasks. taglibs
Re: Justifying Struts
1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. It has not gone too far. If you don't like MVC, you've chosen the wrong tool. You don't need Struts or Java, just use some scripting language like PHP. Form validation is done via an xml config. file and many times there is no code required. This is known as the Validator and is based on the Jakarta commons-validator. You need to subclass ValidatorForm or use DynaValidatorForm. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? You can do this with DynaForms. You configure each been in struts-config.xml and Struts handles it as if you coded a Java class. This approach leads to 1 config file for beans and the rest of the app (struts-config.xml), 1 config file for validation (validation.xml), and 1 Action class to handle the submitted form. 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? JSPs should not talk to EJBs directly, that is a known best practice. Struts is a web tier controller framework for turning web requests into business layer calls. 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. There is no Java scripting language, there is only Java the OO language. Using scriptlets in JSPs is now considered an obsolete technique for many reasons you can find on the net. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. I'm not sure what you mean by this; Java webapps are real world programming. The JSTL provides a common set of reusable taglibs that all Java web programmers are expected to know. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Performance is known to be quite good but no one has taken the time to get actual numbers. Feel free to do this analysis and let us know the results. The only reason people push Struts is because they've found it useful and are excited about using it. Struts will most definitely not be the weakest link in your webapps performance. Database access and network speeds are usually the 2 slowest components. It sounds like you have the wrong expectations for Struts/Java web programming. This is not designed as a scripting environment. MVC webapps are designed to solve the numerous maintenance and productivity problems associated with scripted apps in PHP, ASP, Perl, etc. David Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Justifying Struts
a) See the thread about Is it worth it? on JavaRanch at http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topicf=58t= 001008 b) See specific comments below... I'll try not to repeat comments already made... 1) I like to have my front end developers do form (field) validation. That's fine. You can let them write normal HTML and JavaScript, reinventing the wheel on each page. You don't have to make a form bean for each form or action. Be warned though that when your SQL update or insert blows up because someone's JavaScript wasn't on par, well, don't cry about it here; you won't get much sympathy (as you've probably already noticed). How about this one from my RL experience... I filled out a eBiz order form and mis-keyed my CC exp date. My transaction was rejected, and I was returned to the form... with nothing in it! I had to re-key everything. The Struts HTML tags take care of this problem for you, rather than having to trust that the browser will cache it or the user won't mind re-keying everything. HINT: If a user has to re-key something, they probably won't, resulting in lost business. 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? The key is that Struts helps you control the flow. You can skeleton out a whole app before it's even possible to write the business logic. I speak from experience here--I had a whole app laid out and assembled 6 months before the DBA's finished the schema for my data mart. I dropped in the logic, and voila, everything worked. Struts is *not* a business logic framework. It *is* a VC framework, waiting for your M. =) Trust me when I say once you learn it, it will save you time. 4) We use a very small subset of Java in JSPs. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. How about this argument: Someone new comes in to maintain your app. They don't know a thing about Java or any other programming language, but they do know HTML. They start looking at loops, declarations, etc. and they panic. OTOH, if they look at something with a name and attributes, and it looks like an HTML tag, they can probably figure it out. If you're already using Beans, I don't know what the big deal is with tags. Tag syntax is cleaner than the Java. It provides reuse. (In fact, the servlet engine can reuse tag instances.) 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). The key here is that Struts does everything for you that you'd have to write yourself. If you want to write it yourself, feel free. Meanwhile, I've got a set of wheels and I'm off building apps. =) David Hibbs Staff Programmer / Analyst Distributed Applications Development and Support American National Insurance Company - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justifying Struts
In general I do not sell, or advocate Struts. If they like it, they like. Have you looked at DynaForms? I think Dyna this and that is not best practice. (JSTL, Model 1, Unit testing)
Re: Justifying Struts
[EMAIL PROTECTED] wrote: I am looking at potential frameworks for a new project. I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. I think you don't have to validate the fields in your bean. You can use the validator plugin(?) to do javascript validation if you wish. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? See the link here : http://jakarta.apache.org/struts/faqs/newbie.html#separate 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. Well the whole idea is to avoid the scripting that you mentioned. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, True; a loop is definately a loop, but consider the use for taglibs in this case, would you want to write a loop in a jsp page if there was a taglib that did what you wanted? I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. Really? What do you think a taglib is made of? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Justifying Struts
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 10:44 AM To: [EMAIL PROTECTED] Subject: Justifying Struts I am looking at potential frameworks for a new project. I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. No need to write beans for the client side validations .. Have a look at how Validator works .. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? You can use DynaForms for that .. In that you dont have to write a form bean for each form .. Do read the docs for that 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? What type of overhead are you talking about ?? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. So ??? 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. Using taglibs instead of Scriplets makes the code more clean .. As far as I know there are no overheads in using taglibs .. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Performance is not a issue .. There have been a lot of threads on this ... Mike Mike .. U need to put some more hours reading Struts docs .. rather then straight away jumping to conclusions .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justifying Struts
I'm sorry man, you're reservations are mostly wrong. one thing you have to bare in mind is that we're not all as clever as you, in fact i'd argue that I'm very stupid and many people are as equally stupid. If you've managed to maintain an MVC pattern using model 1 techniques what are you doing researching struts? Model 1 techniques were also attempts to encourage MVC but html'ists who are keen to overcome their programmer envy would break the pattern, if you don't have this problem and your current development practices don't break this pattern you don't need struts then do you? I'm interested in how many times oh that's easy is said in your team, how much unaccounted time pops up on your projects especially when completing easy tasks. taglibs have value in the real world and the struts taglibs more so, the overhead isn't that great and are far less than the cognitive overheads that some ropey scriptlet writing can cause. while i understand your preference for scriptlets, putting your team forward as the sole inhabitance of the real world sounds a little incongruous with the model 1 utopia that you're all living in. Anyway there are numerous threads like yours on this group that have been posted over the last few weeks. take a read. i'd argue that your position requires justification not struts. cheers mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Justifying Struts
Maybe he should also drop java and the servlet api while he is at it - after all you can do all of that stuff in assembly code. How hard is it to implement a web server? - just listen on the port, send some text back and forth. Piece of cake. Run a lot faster too without all that unneccesary overhead the jvm imposes. snip application developers, who are basically scripters (not OO developers) /snip Oh we are just scripters are we? I suppose its true - real programmers write straight to the metal - none of this high level language stuff... design patterns are for quiche eaters... http://www.pbm.com/~lindahl/real.programmers.html http://www.psych.usyd.edu.au/pdp-11/rp.html Ok thats probably enough since its still only Thursday... ;- -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 17:10 To: Struts Users Mailing List Subject: Re: Justifying Struts I'm sorry man, you're reservations are mostly wrong. one thing you have to bare in mind is that we're not all as clever as you, in fact i'd argue that I'm very stupid and many people are as equally stupid. If you've managed to maintain an MVC pattern using model 1 techniques what are you doing researching struts? Model 1 techniques were also attempts to encourage MVC but html'ists who are keen to overcome their programmer envy would break the pattern, if you don't have this problem and your current development practices don't break this pattern you don't need struts then do you? I'm interested in how many times oh that's easy is said in your team, how much unaccounted time pops up on your projects especially when completing easy tasks. taglibs have value in the real world and the struts taglibs more so, the overhead isn't that great and are far less than the cognitive overheads that some ropey scriptlet writing can cause. while i understand your preference for scriptlets, putting your team forward as the sole inhabitance of the real world sounds a little incongruous with the model 1 utopia that you're all living in. Anyway there are numerous threads like yours on this group that have been posted over the last few weeks. take a read. i'd argue that your position requires justification not struts. cheers mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Justifying Struts
it must be a thursday, (i) never could get the hang of thurdays but then i guess this should be left 'til friday :o) On Thursday, May 29, 2003, at 10:37 Europe/London, Andrew Hill wrote: Maybe he should also drop java and the servlet api while he is at it - after all you can do all of that stuff in assembly code. How hard is it to implement a web server? - just listen on the port, send some text back and forth. Piece of cake. Run a lot faster too without all that unneccesary overhead the jvm imposes. snip application developers, who are basically scripters (not OO developers) /snip Oh we are just scripters are we? I suppose its true - real programmers write straight to the metal - none of this high level language stuff... design patterns are for quiche eaters... http://www.pbm.com/~lindahl/real.programmers.html http://www.psych.usyd.edu.au/pdp-11/rp.html Ok thats probably enough since its still only Thursday... ;- -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 17:10 To: Struts Users Mailing List Subject: Re: Justifying Struts I'm sorry man, you're reservations are mostly wrong. one thing you have to bare in mind is that we're not all as clever as you, in fact i'd argue that I'm very stupid and many people are as equally stupid. If you've managed to maintain an MVC pattern using model 1 techniques what are you doing researching struts? Model 1 techniques were also attempts to encourage MVC but html'ists who are keen to overcome their programmer envy would break the pattern, if you don't have this problem and your current development practices don't break this pattern you don't need struts then do you? I'm interested in how many times oh that's easy is said in your team, how much unaccounted time pops up on your projects especially when completing easy tasks. taglibs have value in the real world and the struts taglibs more so, the overhead isn't that great and are far less than the cognitive overheads that some ropey scriptlet writing can cause. while i understand your preference for scriptlets, putting your team forward as the sole inhabitance of the real world sounds a little incongruous with the model 1 utopia that you're all living in. Anyway there are numerous threads like yours on this group that have been posted over the last few weeks. take a read. i'd argue that your position requires justification not struts. cheers mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe
RE: Justifying Struts
I'm with you, Mike! That's why I stopped using this confounded framework and returned to good ole ASP Mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Justifying Struts
Wake up mate, your having another nightmare... those overtime induced ASP flashbacks can be heavy d00d -Original Message- From: Mark Galbreath [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 20:17 To: 'Struts Users Mailing List' Subject: RE: Justifying Struts I'm with you, Mike! That's why I stopped using this confounded framework and returned to good ole ASP Mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justifying Struts
but not completely... :) On Thursday, May 29, 2003, at 07:17 AM, Mark Galbreath wrote: I'm with you, Mike! That's why I stopped using this confounded framework and returned to good ole ASP Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Justifying Struts
Ya I just started coding a project in PHP. I love the spaghetti code and complete lack of structural rules :-D Other such loves... 1) I love how there are no namespaces 2) I love the mish-mash of procedural and object oriented principals. 3) I love the lack of scope to store objects or basic string data in general (no application scope, weak request scope, and, from #2, a procedural/oo page scope that makes you wanna scream) 4) Loose (obsurdly) typing that can and DOES encourage crappy programming. 5) I love how at every chance they attempt to borrow from java, but due to their underpinnings always wind up seriously short and still find room to cut down java. My advice to PHP... MAKE UP YOUR MIND!!! :-)) Anyways, that's my .02, Brandon Goodin -Original Message- From: Mark Galbreath [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 6:17 AM To: 'Struts Users Mailing List' Subject: RE: Justifying Struts I'm with you, Mike! That's why I stopped using this confounded framework and returned to good ole ASP Mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java, with the scripting language called Java that we use in JSPs. We use a very small subset of Java in JSPs. 5) Based on #4, I don't particularly care for taglibs either. Again, we are simply using Java to do simple scripting. Loops are probably the most complex thing we do. So why add the extra overhead of taglibs. A loop is a loop whether it has the syntax of Java or a taglib. Plus, if I want my front-end developers to get any experience with serious development, I'd rather have them dealing with Java as opposed to taglibs, which have no value in the real world of programming. 6) Performance is unknown. I've looked through the mail archives and have seen requests for performance figures, but no answers (plenty of folks pushing Struts though). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Justifying Struts
Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? Have you looked at DynaForms? 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. I think in some cases though, validation constraints are complex enough they cannot all be done through simple means. Once you start adding on layers of complexity, without a good pattern to follow, you may get each developer doing it slightly differently. -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 5:38 AM To: Struts Users Mailing List Subject: RE: Justifying Struts Maybe he should also drop java and the servlet api while he is at it - after all you can do all of that stuff in assembly code. How hard is it to implement a web server? - just listen on the port, send some text back and forth. Piece of cake. Run a lot faster too without all that unneccesary overhead the jvm imposes. snip application developers, who are basically scripters (not OO developers) /snip Oh we are just scripters are we? I suppose its true - real programmers write straight to the metal - none of this high level language stuff... design patterns are for quiche eaters... http://www.pbm.com/~lindahl/real.programmers.html http://www.psych.usyd.edu.au/pdp-11/rp.html Ok thats probably enough since its still only Thursday... ;- -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 17:10 To: Struts Users Mailing List Subject: Re: Justifying Struts I'm sorry man, you're reservations are mostly wrong. one thing you have to bare in mind is that we're not all as clever as you, in fact i'd argue that I'm very stupid and many people are as equally stupid. If you've managed to maintain an MVC pattern using model 1 techniques what are you doing researching struts? Model 1 techniques were also attempts to encourage MVC but html'ists who are keen to overcome their programmer envy would break the pattern, if you don't have this problem and your current development practices don't break this pattern you don't need struts then do you? I'm interested in how many times oh that's easy is said in your team, how much unaccounted time pops up on your projects especially when completing easy tasks. taglibs have value in the real world and the struts taglibs more so, the overhead isn't that great and are far less than the cognitive overheads that some ropey scriptlet writing can cause. while i understand your preference for scriptlets, putting your team forward as the sole inhabitance of the real world sounds a little incongruous with the model 1 utopia that you're all living in. Anyway there are numerous threads like yours on this group that have been posted over the last few weeks. take a read. i'd argue that your position requires justification not struts. cheers mark I've heard about Struts and have researched it over the last few hours. The MVC approach makes sense, but I'm still not sold on it yet. Here are some doubts I have. 1) I think the separation of presentation (view) from the model and controller has gone too far (or probably is not done well in Struts). For example, I like to have my front end developers do form (field) validation. These developers should not have to write beans to do this (all examples I've seen so far do form validation in Java beans). This somewhat contradicts the J2EE development model where application developers, who are basically scripters (not OO developers), do the front end work. 2) There is just too much junk to write to do a simple form. The samples I've seen have involve too many files to do a simple form. Plus, why should I have to write a new bean for each form. Why can't the bean either be generated automatically or there be a general purpose bean (with properties that are created dynamically) that works for all forms? 3) We already separate business logic nicely, usually by encapsulating the logic in beans or EJBs. By the time the application developers get to work writing JSP/HTML, they are not writing any business logic. So why add the overhead of Struts (or any other framework)? 4) Because we separate out business logic into beans and EJBs, Java is simply used as a scripting langauge in our JSPs - in just the same way that VBScript is used in Active Server Pages. We try not to confuse the object oriented language called Java
