Taglib
Does someone knows a good taglib to display a "popup frame", charts and so on...? Thanks for sharing!
Re: Want dynamic menus
Struts menu is just fine, works with latest stuff and can be attached to DB too, there is a nice tutorial. If the stuff works just fine, why do you need updates? :) Cheers, Danny Antony Paul schrieb: Hi all, I am looking for a component to create menus in Java web applications. I want to have a drop down menu with many levels and a tree menu with expand/collapse. It should be configurable to work in client side/serverside. It should work with Struts/Spring and should be Apache or compatible licence. What are the suggestions ?. On googling I found Struts Menu, Struts Layout, Jenkov Prizetags. I found Struts Menu to be good one but it seems that it is not actively developed now. The last release was in Sep 2004. The MyFaces Tomahawk tree control is excellent but it requires JSF. -- rgds Antony Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Want dynamic menus
Where to find the struts menu tutorial? Peter -Ursprüngliche Nachricht- Von: news [mailto:[EMAIL PROTECTED] Auftrag von Danny Lee Gesendet: Dienstag, 13. Dezember 2005 10:45 An: user@struts.apache.org Betreff: Re: Want dynamic menus Struts menu is just fine, works with latest stuff and can be attached to DB too, there is a nice tutorial. If the stuff works just fine, why do you need updates? :) Cheers, Danny Antony Paul schrieb: > Hi all, > I am looking for a component to create menus in Java web applications. I > want to have a drop down menu with many levels and a tree menu with > expand/collapse. It should be configurable to work in client > side/serverside. It should work with Struts/Spring and should be Apache or > compatible licence. What are the suggestions ?. On googling I found Struts > Menu, Struts Layout, Jenkov Prizetags. I found Struts Menu to be good one > but it seems that it is not actively developed now. The last release was in > Sep 2004. The MyFaces > Tomahawk tree control is excellent but it requires JSF. > > -- > rgds > Antony Paul > - 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]
Struts DTD - basic question
Hello all, My struts-config.xml looks for the dtd in the Jakarta website: http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd My validator.xml looks for the dtd in the Jakarta website: http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd And so my validator-rules.xml file. When the above site is in some problem and I want to build my web project, I get this message: "Operation timed out: connect:could be due to invalid address". I would like to hold those dtd's locally. So, where should I put them in my web project? Should it be in the "lib" directory with the struts.jar? Thanks Rivka
Re: Struts DTD - basic question
On Tue, 2005-12-13 at 12:14 +0200, Rivka Shisman wrote: > Hello all, > My struts-config.xml looks for the dtd in the Jakarta website: > http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd > > My validator.xml looks for the dtd in the Jakarta website: > http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd > > And so my validator-rules.xml file. They should be in the struts jar file. Does your DOCTYPE exactly match those of the dtd files? -- Torgeir Veimo <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IBM Portal server V5.0.2.3
And you're sure you're using the correct jar-files? That would be the only thing I could think of that might cause the tag to generate different output from what you're expecting. Sorry I couldn't help more. Kjersti On 13/12/05, Meenakshi Singh <[EMAIL PROTECTED]> wrote: > > yes, I did try that. When I use it without encoding, it doesn't recognize > the .jsp file. > > -Original Message- > From: Kjersti Berg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 13, 2005 12:36 PM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: IBM Portal server V5.0.2.3 > > > Have you tried using a regular struts tag? > > > > We're using the Struts Portal Framework that ships with Webshere Portal > Server, and this works just fine for us. > > Kjersti > On 08/12/05, Meenakshi Singh <[EMAIL PROTECTED]> wrote: > > > > yes I am using WSAD V5.1.1 & using portal server. I have created the > > portlet > > & have deployed it in the portal server. however, the href in one of the > > jsp's is not opening up in the same page where my portlet is showing. It > > opens up on a diff page. That is my problem. How do I make it open in > the > > same page. > > > > That is how I am using the href element in my jsp: > > > href='<%=response.encodeURL(request.getContextPath > > ()+"/jsp/CentralNoSearch.j > > sp")%>' >Search by Central Number > > > > Regards, > > Meenakshi. > > > > -Original Message- > > From: Mark Benussi [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 07, 2005 8:29 PM > > To: 'Struts Users Mailing List'; [EMAIL PROTECTED] > > Subject: RE: IBM Portal server V5.0.2.3 > > > > > > I think what you want is to create a Portlet. Use WebSphere Studio > > Application Developer to create a new Portlet Application and then > install > > this with Portal Server. > > > > -Original Message- > > From: Meenakshi Singh [mailto:[EMAIL PROTECTED] > > Sent: 07 December 2005 11:39 > > To: Struts Users Mailing List (E-mail) > > Subject: IBM Portal server V5.0.2.3 > > > > hiee all, > > > > > > Please help if anyone has used the IBM portal server. > > I have a small struts app deployed on IBM Portal Server V 5.0.2.3 > > I add 2 jsps to the struts application. In one jsp I am putting a link > > with > > a href to point to another jsp. > > When I click on this link after deploying the portlet, it opens the link > > in > > the whole browser window which is not the same as the portal page. I > want > > to open the link in the same portal page. > > > > Would anyone please tell me how I can do that? > > > > Thanks & Regards, > > Meenakshi. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: IBM Portal server V5.0.2.3
yes, I m using the correct jars. I have checked all the jars from a working sample which I got from the web. The samples are working fine. I have even tried two simple jsps(a non-struts example). Even in that a simple href is not getting executed as desired. I am still struggling. Thanks a lot for your suggestions. Regards, Meenakshi. -Original Message- From: Kjersti Berg [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 4:15 PM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: IBM Portal server V5.0.2.3 And you're sure you're using the correct jar-files? That would be the only thing I could think of that might cause the tag to generate different output from what you're expecting. Sorry I couldn't help more. Kjersti On 13/12/05, Meenakshi Singh <[EMAIL PROTECTED]> wrote: > > yes, I did try that. When I use it without encoding, it doesn't recognize > the .jsp file. > > -Original Message- > From: Kjersti Berg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 13, 2005 12:36 PM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: IBM Portal server V5.0.2.3 > > > Have you tried using a regular struts tag? > > > > We're using the Struts Portal Framework that ships with Webshere Portal > Server, and this works just fine for us. > > Kjersti > On 08/12/05, Meenakshi Singh <[EMAIL PROTECTED]> wrote: > > > > yes I am using WSAD V5.1.1 & using portal server. I have created the > > portlet > > & have deployed it in the portal server. however, the href in one of the > > jsp's is not opening up in the same page where my portlet is showing. It > > opens up on a diff page. That is my problem. How do I make it open in > the > > same page. > > > > That is how I am using the href element in my jsp: > > > href='<%=response.encodeURL(request.getContextPath > > ()+"/jsp/CentralNoSearch.j > > sp")%>' >Search by Central Number > > > > Regards, > > Meenakshi. > > > > -Original Message- > > From: Mark Benussi [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 07, 2005 8:29 PM > > To: 'Struts Users Mailing List'; [EMAIL PROTECTED] > > Subject: RE: IBM Portal server V5.0.2.3 > > > > > > I think what you want is to create a Portlet. Use WebSphere Studio > > Application Developer to create a new Portlet Application and then > install > > this with Portal Server. > > > > -Original Message- > > From: Meenakshi Singh [mailto:[EMAIL PROTECTED] > > Sent: 07 December 2005 11:39 > > To: Struts Users Mailing List (E-mail) > > Subject: IBM Portal server V5.0.2.3 > > > > hiee all, > > > > > > Please help if anyone has used the IBM portal server. > > I have a small struts app deployed on IBM Portal Server V 5.0.2.3 > > I add 2 jsps to the struts application. In one jsp I am putting a link > > with > > a href to point to another jsp. > > When I click on this link after deploying the portlet, it opens the link > > in > > the whole browser window which is not the same as the portal page. I > want > > to open the link in the same portal page. > > > > Would anyone please tell me how I can do that? > > > > Thanks & Regards, > > Meenakshi. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > 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: Want dynamic menus
On 12/13/05, Danny Lee <[EMAIL PROTECTED]> wrote: > > Struts menu is just fine, > works with latest stuff and can be attached to DB too, there is a nice > tutorial. > > If the stuff works just fine, why do you need updates? :) I just want to standardise on one thing. I dont like spending time to learn/develop another component after six months. -- rgds Antony Paul http://www.geocities.com/antonypaul24/
Re: Struts DTD - basic question
Shalom there, http://jakarta.apache.org is dead :(, have the same problem. yes you can hold the stuff localy. Just put it in your /lib/ folder... when jackarta's up, I'll do it too. Cheers Danny Rivka Shisman schrieb: Hello all, My struts-config.xml looks for the dtd in the Jakarta website: http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd My validator.xml looks for the dtd in the Jakarta website: http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd And so my validator-rules.xml file. When the above site is in some problem and I want to build my web project, I get this message: "Operation timed out: connect:could be due to invalid address". I would like to hold those dtd's locally. So, where should I put them in my web project? Should it be in the "lib" directory with the struts.jar? Thanks Rivka - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
JSF is more powerful than Struts in many ways. In fact, the original creator of Struts, Craig McClanahan, was the co-spec lead of JSF expert group and he is one of the author of Shale (Struts sub-project aimed at extending JSF). JSF provides all the Struts features, ie. validation, conversion, navigation, messages, ... and all those features are extendable. But JSF dissociates itself from Struts in a lot of areas. First, it is component oriented so it is easier to reuse code between applications and easier to understand. Plus, the components are STATEFUL, they keep their state between request and that is a big advantage of JSF. In Struts, only the forms input controls were stateful and only if your form beans had session scope. Also, JSF provides a fine-grained event model à la Swing compare to the coarse-grained event model of Struts (receive request, do something). Finally, the best part of JSF comes from method and value binding wich allows you to use normal Java Beans for your controller (think of it as a Dispatch Action merged with an Action Form). It so easy to test compare to Struts action and action forms. I have been developping for several years with Struts and I didn't like it (even if it was making things better then using only jsp/servlets). There were so many problems and it was hard to reuse anything from that code. Trust me, if you liked Tapestry (wich is a reliable alternative in my mind), you will probably love JSF. The rough spot of JSF in my opinion is JSP integration wich is in my mind a big mistake but there are some good alternatives out there (Shale Clay and facelet). About Shale, Struts Shale is just a subproject of Struts. It has nothing to do with it, it just shares the user community. Struts is going to stay a classical Action oriented framework while Shale is a framework built around JSF. Shale is kind of an experimental ground to add things that weren't cover by JSF spec. It adds stuff you are used to in Struts. For exemple, with Shale you can have application wide functionnalities like with Struts RequestProcessor. Shale also add page functionalities, ie kind of like when you have an action in Struts wich is responsable to load data before displaying the view. Shale also add the concept of dialog by bringing the Spring Webflow implementation to the JSF world. I haven't tried it yet but seems quite powerful. With Shale, you also have support for Apache commons validators and so client-side validation. Finally, Shale-Clay plug-in allows you to reuse some subview easily and provide you integration with different choice of view technologies (XHTML, XML) to use instead of JSP. Well, that's the best I can say in such a short text but there a lot more then that about JSF. You should start reading to make your own opinion. One advice, there's a lot of FUD spread around JSF right now so try it by yourselft first before listening to other people. But there are good alternatives to JSF. I have not tried all of them but there all several other components frameworks like Tapestry, Echo and Wicky. On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > I'm starting to begin looking at JSF in part because of what I've read > here on the Struts mailing list. i.e. Struts is embracing JSF, many > developers see it as inevitable. I have some experience with Tapestry and > Ruby on Rails so I'm excited about component frameworks. However, what I > don't know, having just started learning JSF is how ready it is. I can't > take wars developed in Java Studio Creator and deploy them to WebSphere > (we use WebSpere where I work) and I'm not sure how it stacks up to Struts > in terms of input validation, ease of integration with a business tier and > Hibernate and other common J2EE issues. Can anyone with experience give me > an idea if now is the time to jump in the water? > > The reason I ask here is because of the nature of Struts creating new > projects to extend and enhance the JSF API. I don't know (with that in > mind) if that's a sign of JSF not being fully baked, or not being up to > par with what most Struts users are used to. > > This is one of those situations where I want to pick the right horse. My > experience has been that usually the open source solution is the better > solution. See Ant, Struts, Spring, Hibernate, Tomcat as examples. So > because of licensing and who created the reference implementation I'm > naturally a little skeptical of JSF. Excited, but skeptical. Hopefully > someone can fill me in or at least explain what holes Shale is meant to > fill. > > Preston > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help!
Friends, I have to modify my application so that it will create a logs folder(Where error messages are logged in either info,error,warn priority etc. files)having name as per the user name who is logged in the application.Also,that folder should have Timestamp. 1>Can anyone guide me to tell how the Userdefined Folder for logs has to be created? 2>Is it possible by Log4j or i hae to make changes in server.xml to write my own logs folder? Please guide Regards, Shailesh
Re: Struts DTD - basic question
At 1:23 PM +0100 12/13/05, Danny Lee wrote: Shalom there, http://jakarta.apache.org is dead :(, have the same problem. yes you can hold the stuff localy. Just put it in your /lib/ folder... when jackarta's up, I'll do it too. Struts, Tiles, and Validator all are distributed with the correct DTDs (as well as several historic versions) packaged in the JAR. If you have the correct DOCTYPE declaration in your XML file, the DTD will be read as a classpath resource rather than over the internet. People generally don't understand that the PUBLIC identifier in the DOCTYPE is literally an identifier. It is an unstructured text string which must exactly match the value which is encoded in the validation Java code. (Well, it looks structured, but the process of identifying the DTD is based on a pure string match.) I recently collected the correct DOCTYPE declarations for the various XML files which Struts (or common Struts libraries) wants to validate; if you use these values, there should be no attempt to retrieve the DTD over the internet: Struts 1.3 http://struts.apache.org/dtds/struts-config_1_3.dtd";> Struts 1.2 http://struts.apache.org/dtds/struts-config_1_2.dtd";> Struts 1.1 http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd";> Struts 1.0 http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd";> Servlet 2.3 http://java.sun.com/dtd/web-app_2_3.dtd";> commons-validator 1.2 "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.2.0//EN" "http://jakarta.apache.org/commons/dtds/validator_1_2_0.dtd";> commons-validator 1.1.3 "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1.3//EN" "http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd";> commons-validator 1.1 "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN" "http://jakarta.apache.org/commons/dtds/validator_1_1.dtd";> commons-validator 1.0.1 "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0.1//EN" "http://jakarta.apache.org/commons/dtds/validator_1_0_1.dtd";> commons-validator 1.0 "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0//EN" "http://jakarta.apache.org/commons/dtds/validator_1_0.dtd";> Tiles 1.1 http://struts.apache.org/dtds/tiles-config_1_1.dtd";> Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DTD - basic question
On 12/13/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > My struts-config.xml looks for the dtd in the Jakarta website: > http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd > > My validator.xml looks for the dtd in the Jakarta website: > http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd > > And so my validator-rules.xml file. > > When the above site is in some problem and I want to build my web > project, I get this message: "Operation timed out: connect:could be due > to invalid address". What version of Struts are you using, and how are you building your project? It sounds like your IDE or build tool might need to be configured to find the resources locally. (This is _not_ happening at runtime, right?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DTD - basic question
Hi Joe, thanks for your answer, now I realy understand how this stuff works :) But it still don't works with validator. JAR is right and in scope, DTD is there in jar, DOCTYPE is right too but Eclipse allways tries to search for it online... Cheers, Danny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DTD - basic question
At 3:41 PM +0100 12/13/05, Danny Lee wrote: Hi Joe, thanks for your answer, now I realy understand how this stuff works :) But it still don't works with validator. JAR is right and in scope, DTD is there in jar, DOCTYPE is right too but Eclipse allways tries to search for it online... I think I missed that part; the suggestions I had are only for running Struts; not for work in an IDE. Eclipse has an XML Catalog (at least 3.1 with the Web Tools installed; I'm not sure where that came in). With that, you can do a similar process -- register a public ID and tell Eclipse where it can find a locally stored copy of that DTD. You can get a copy from the URL (if the server is working) or from a Struts JAR or the SVN repository. For other IDEs, I can't say, but they could all offer similar services. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validator and Javascript
Thank you all. This should solve my problem. -Original Message- From: Laurie Harper [mailto:[EMAIL PROTECTED] Sent: Monday, December 12, 2005 2:32 PM To: user@struts.apache.org Subject: Re: Validator and Javascript From the documentation: "The dynamicJavascript and staticJavascript attributes default to true, but if dynamicJavascript is set to true and staticJavascript is set to false then only the dynamic JavaScript will be rendered. If dynamicJavascript is set to false and staticJavascript is set to true then only the static JavaScript will be rendered which can then be put in separate JSP page so the browser can cache the static JavaScript." So, you can create a 'validation.jsp' containing and reference this JSP with a tag in any JSP which uses validation -- or you can save the result of processing validation.jsp into a static file and reference that, to avoid the JSP processing for the static content. L. Deepa Khetan wrote: > I dint understand how to copy the static javascript on the > validator.xml to another .js file? Can u please elaborate? > > On 12/10/05, Laurie Harper <[EMAIL PROTECTED]> wrote: >> Tony Santinello wrote: >>> Hi, >>> >>> I'm using Struts 1.2.7 and I'm using commons-validator to validate >>> my forms. Can someone tell me why validator includes all the >>> javascript functions when rendering the jsp page? >>> >>> Even including javascript functions that I'm not using in >>> validation.xml, such as creditcard validation or integer validation? >>> >>> Is there anyway to include just the javascript my jsp needs and not >>> all the extra javascript? >> There's two types of Javascript emitted by the validator framework: >> static and dynamic. The static script includes all the code that >> doesn't vary from form to form, whereas the dynamic stuff is >> dependent on the validations you've configured for the form. >> >> The html:javascript, by default, emits all the static code every time >> and generates additional dynamic code appropriate to the form. You >> can tell it not to emit the static Javascript at all (in which case >> you need to include it elsewhere on the page, directly or by >> reference), but you can't tell it to emit only a sub-set of the static code. >> >> Your best bet is to copy the static Javascript into a seperate .js >> file, include that in the head of your page, and turn it off in the >> html:javascript tag. Browser caching will then avoid the user having >> to download the static code everytime, which is one step better than >> inlining a sub-set of it. >> >> L. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
On Tue, December 13, 2005 7:27 am, Alexandre Poitras said: > One advice, there's a lot of FUD spread around JSF right now > so try it by yourselft first before listening to other people. This is perhaps the best bit of advice anyone could give. For whatever reason, JSF has engendered a great deal of strong feelings on both sides of the like it/love it fence. Do yourself a favor and don't even bother with opinions at this point. Just play with it and see what you think. One seemingly universal truth is that if you are going to like it, chances are it will take a little while. I haven't talked to many people that instantly loved it, but I have spoken to numerous people who didn't like it at first and gradually they came to like it a great deal. So give it a fair shake before you decide. If you really want another opinion for your tally sheet, put me down as not a big fan. My JSF experiences have not been encouraging, but notice I said experienceS... I keep going back and giving it another shot, hoping the epiphany that many people seem to have will hit me too. It hasn't yet though. It seems that for everything I see that is good about it, I find something that I think is bad, so on balance I remain unconvinced. But, my opinion is no better than anyone else', so give it a try yourself, and give it some time to grow on you, and see if it does. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts DTD - basic question
Thanks again Joe, now I've configurated the stuff for Eclipse, and it works. Cheers, Danny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Is JSF ready?
Frank W. Zammetti wrote: If you really want another opinion for your tally sheet, put me down as not a big fan. My JSF experiences have not been encouraging [...] Just out of curiosity and for the sake of completeness, what didn't you like/etc. about it? I'm also trying to decide whether or not to bother, as I'm tending towards much lighter-weight/more agile webapp methodologies these days. JSF seems in some ways like ASP.NET, but that's a very high-level haven't-checked-it-out-much viewpoint. If it can be as rapid as ASP but w/o dealing with any number of Microsoft issues, including technical and philosophical, it could be neat on those bad days J2EE is a requirement. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is JSF ready?
Frank - When JSF matures and you have looked over it again a few times, but possibly still not had your epiphany. Would you remain happy with the technologies you know now to see you through the seemingly Shale/JSF dominated future of Java web frameworks? I think the question that no-one has asked is what happens if you don't learn and embrace JSF now and get it on your list of skills? Even if you despise it (I have no preference yet), is it not a good move to get familiar with it regardless (if you can)? >From my perspective JSF seems like it is going to become quite a large part of the scene for a while until it is usurped by something greater. As Craig pointed out in a previous post though, as struts has, JSF might dominate for a good 5 years or more and be THE predominate framework that people choose to use just as struts classic has been. Chris -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: 13 December 2005 15:17 To: Struts Users Mailing List Subject: Re: Is JSF ready? On Tue, December 13, 2005 7:27 am, Alexandre Poitras said: > One advice, there's a lot of FUD spread around JSF right now > so try it by yourselft first before listening to other people. This is perhaps the best bit of advice anyone could give. For whatever reason, JSF has engendered a great deal of strong feelings on both sides of the like it/love it fence. Do yourself a favor and don't even bother with opinions at this point. Just play with it and see what you think. One seemingly universal truth is that if you are going to like it, chances are it will take a little while. I haven't talked to many people that instantly loved it, but I have spoken to numerous people who didn't like it at first and gradually they came to like it a great deal. So give it a fair shake before you decide. If you really want another opinion for your tally sheet, put me down as not a big fan. My JSF experiences have not been encouraging, but notice I said experienceS... I keep going back and giving it another shot, hoping the epiphany that many people seem to have will hit me too. It hasn't yet though. It seems that for everything I see that is good about it, I find something that I think is bad, so on balance I remain unconvinced. But, my opinion is no better than anyone else', so give it a try yourself, and give it some time to grow on you, and see if it does. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This email originated externally and has been scanned by MessageLabs __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Struts DTD - basic question
Hi again and thank you all for your help Danny, I'm working with RAD (Rational Application Developer) of IBM as an IDE, and it's baseed on Eclipse. Can you please tell me where to configure the DTD locally? Thanks Rivka -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Danny Lee Sent: Tuesday, December 13, 2005 5:18 PM To: user@struts.apache.org Subject: Re: Struts DTD - basic question Thanks again Joe, now I've configurated the stuff for Eclipse, and it works. Cheers, Danny - 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]
[OT] Re: Is JSF ready?
Chris McCormack wrote: I think the question that no-one has asked is what happens if you don't learn and embrace JSF now and get it on your list of skills? Even if you despise it (I have no preference yet), is it not a good move to get familiar with it regardless (if you can)? I think this is dependent on whether or not you'll program anything they tell you (programming whore) to or if you have a set of criteria for what you're willing to do. This is the same for any technology, it's just that J2EE spawns acronyms like a demon-possessed bunny because it HAS to to survive and even _approach_ usability. I personally simply don't have the time to "get familiar" with all the latest acronyms, and the vast majority of sites I work on simply won't benefit from almost every J2EE acronym/technology I run across. As an off-topic example, I left a decent game programming position because I thought spending a year working on a 3DO project would be a waste of time as I felt the technology would die. Remember the 3DO? Exactly: good choice. (Although JSF has a WAY better chance of survival than the 3DO ever did :) Should I worship every god/dess just in case they're the one/many true One/s? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsp:includes or c:imports of action AND new tag for in struts config
I solved this problem, by using the source of the struts IncludeAction.
I hijacked that code and did my List generation before the the
RequestDispatcher formward call, so it looks like:
Action snippet: **
List menuItems = getMenuItemsList();
req.setAttribute("menuitems", menuItems);
RequestDispatcher rd =
servlet.getServletContext().getRequestDispatcher("/WEB-INF/jsp/frontend/footer_include.jsp");
// Forward control to the specified resource
rd.include(req, res);
// Tell the controller servlet that the response has been created
return (null);
**
So I'm wondering, has anyone ever heard of a proposal to allow for an
tag inside an tag in the struts config, to complement
the tag? so instead of the above i could just config like
this:
It would seem like useful functionality and a more clear and struts like
solution to the above problem.
dave
On Mon, 2005-12-12 at 18:12 -0800, David Evans wrote:
> Hello all,
>
> I have a requirement for a dynamically created menu on all pages of a
> web site i am creating. So i created an action that creates a List of
> MenuItems, and then forwards to a jsp that uses jstl to forEach through
> the list and generate the appropriate html. the jsp page only has the
> snippet of html for the menu div of the page. I am including this action
> in "static" html pages via the use of apaches SSI module like this:
>
>
> and thought i was going to use jsp:include to include it in all of the
> jsp pages to which my applications actions are forwarding, like this:
>
>
> However when i attempt to do that i get a:
>
> java.lang.IllegalStateException: Cannot forward after response has been
> committed
>
> This does work:
> http://www.domainname.com/apps/footer"; />
> but i'd prefer not to have to use that, because then i'll have to change
> it when things move from dev to production, so far my jsp's have no site
> specific information, so i can just copy them.
>
> So can someone tell me how/if i can include the results of an action in
> a jsp that is being forwarded to from another action?
>
> Thanks
>
> Dave
>
>
> -
> 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: Want dynamic menus
Well, if you want to stick on one thing, I can understand it. But if there's some 2004 stuff still works with actual stuff and ppl use it, *maybe* it more likely it will work in the future, then any fresh stuff (which maybe just too buggy/unpopular for further development). Cheers, Danny Antony Paul schrieb: On 12/13/05, Danny Lee <[EMAIL PROTECTED]> wrote: Struts menu is just fine, works with latest stuff and can be attached to DB too, there is a nice tutorial. If the stuff works just fine, why do you need updates? :) I just want to standardise on one thing. I dont like spending time to learn/develop another component after six months. -- rgds Antony Paul http://www.geocities.com/antonypaul24/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] using Sun java studio creator or Sun Java Studio Enterprise
Hi Has anyone used either of the tools from Sun, what is the difference between them? do they support struts development? What is your opinion about them, currently i am using myeclipseide are they worth switching? Is there a way to migrate existing projects Ashish __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
On 12/13/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > First, it [JSF] is component oriented so it is easier to reuse > code between applications and easier to understand. Struts can be easily made component-oriented. > Plus, the > components are STATEFUL, they keep their state between request and > that is a big advantage of JSF. In Struts, only the forms input > controls were stateful and only if your form beans had session scope. Have JSF invented another method to keep application state? In Struts one can use action form both for input and output, which makes it a conversational input/output object, a view buffer, a managed bean if you will. > Also, JSF provides a fine-grained event model à la Swing compare to > the coarse-grained event model of Struts (receive request, do > something). DispatchAction et al? > Finally, the best part of JSF comes from method and value > binding wich allows you to use normal Java Beans for your controller > (think of it as a Dispatch Action merged with an Action Form). Combining DispatchAction with ActionForm would be a simple change for Struts, without breaking compatibility. For some reason that did not happen [yet?]. JSF has its benefits, but the features that you quoted are not unique for JSF. The same practices can be easily used with Struts. > Alexandre Poitras > Québec, Canada Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Is JSF ready?
On Tue, December 13, 2005 10:25 am, Dave Newton said: > Just out of curiosity and for the sake of completeness, what didn't you > like/etc. about it? I'm also trying to decide whether or not to bother, > as I'm tending towards much lighter-weight/more agile webapp > methodologies these days. Well, to be very honest, I can't emumerate a lot of very specific things I liked or didn't like. My current state of mind is more of a gut feeling kind of thing (which is a big part of the reason I continue to give it a chance and keep an open mind- my gut could be wrong!). That being said, there *are* a few at least somewhat specific things... * Contrary to what many people say, I don't find it to be any simpler than Struts or other frameworks I've looked at. I have to factor in the fact that I'm not a JSF expert with this next statement, but I actually find it to be somewhat *more* complex. I suspect there needs to be a differentiation between conceptual complexity and hands-on complexity though. As far as hands-on goes, what code/config you actually need to write, I haven't seen anything that makes me think its any more complex, at least not to any substantial degree. But conceptually, and probably because you need to trust the framework a little more to do more for you, I think JSF is a bit harder to get your brain around. There is a bit more "mystery", so to speak, in what JSF is doing under the covers, and if you are a person, like me, who has a tough time having all those details hidden from you, it can paradoxically be harder to understand what is actually simpler. * While this isn't a failing of JSF, it has to be factored in: there is a lack of *good* examples and documentation in my opinion. Oh, there is *plenty* of examples and documentation in general, but it seems to all be way too simplistic to be of any real help. Or it's a kitchen sink thing and you can't parse out the necessary from the fluff. Note that I'm talking about JSF in general... Shale has a lack of examples, although the documentation looks pretty good, but there are no tutorials that I'm aware of... none of this matters for Shale though because its still coming together and thus you cut it some slack. JSF as a whole though is supposed to be mature, and part of maturity in my opinion is good documentation and examples. * When your working in Struts, there are canonical answers to most questions, best-practices ways of doing things. The same is true of JSF. However, with Struts, if you want to "go off the reservation", so to speak, you can almost always do so without fighting the framework. My experience is just the opposite with JSF. If you like the "JSf Way", then you wouldn't have a problem with this, but if you like being in complete control, for me at least, its a problem. While I'm sure you *can* go off the reservation with JSF as well, it seems like much more of a fight. Some people will like the rigidity and standardization JSF can bring, and logically I can see why, but I prefer the flexibility to do it *my* way, and that doesn't seem to be a strong suite of JSF. * Hype. I generally recoil from anything that is hyped as much as JSF is, if for no other reason than I don't like being headrded around under any circumstances. Now, all those doing the hyping may well believe every single word they are saying. I certainly hope that is the case. And in the end they may well wind up being right! However, JSF is not something new. It's been around for quite a while now, and it has yet to set the world on fire. This doesn't make me right and them wrong by the way, but it *does* make you wonder if its all its cracked up to be. I see JSF as being highly desirable for corporate interests, the tool vendors and those that will sell implementations and consulting services and all that, and that worries me. I like the way Struts developed: put it out there with no motivation other than to help people, and let it develop as it will. If JSF had evolved the same way, I'd have one less worry/complaint about it, but as it stands I have to wonder what the real motivation is. Like I said, there isn't much technical points there, it's mostly psychological. However, I don't see those types of objections mattering any less than technical ones. One *should* however be willing to overcome those objections when sufficient reason becomes available, and that's why I continue to keep an open mind. > JSF seems in some ways like ASP.NET, but that's a very high-level > haven't-checked-it-out-much viewpoint. If it can be as rapid as ASP but > w/o dealing with any number of Microsoft issues, including technical and > philosophical, it could be neat on those bad days J2EE is a requirement. That is a fairly accurate comparison in terms of the overall approach. That's also one of the reasons tooling is so important for JSF to succeed: once you can build an application as easily as you can in Visual Studio, more people will be on board.
RE: Is JSF ready?
On Tue, December 13, 2005 10:40 am, Chris McCormack said: > Frank - > When JSF matures and you have looked over it again a few times, but > possibly > still not had your epiphany. Would you remain happy with the technologies > you know now to see you through the seemingly Shale/JSF dominated future > of > Java web frameworks? The future in my opinion is RIA's, and as yet no one has shown me why JSF is better for this than Struts. I have not personally run into all the supposed limitations of the current model, and I regularly develop highly complex RIA's, that's how I make my living. So, for me, JSF doesn't offer me anything that I absolutely need today. What it *does* offer that is worthwild can be done just as easily with Struts... managed bean support is available through Spring or my own DependencyFilter in Java Web Parts... component-based development can be accomplished any number of ways outside JSF, etc., so on and so forth for virtually every part of JSF. The funny thing is, if you change your approach and mindset about web development just a little bit, then many of the problems JSF seeks to solve go away anyway. When you stop thinking in terms of whole page refreshes and strictly server-side actions, JSF, in my opinion anyway, doesn't offer a whole lot, and you can do all of this with Struts today. Granted, you will have to do more of the work, and that is one area where JSF has a clear advantage, but it is just a doable with JSF as with ultimately, and so I have no worries about the future with or without JSF. I don't know what the future will hold. JSF may win the day on nothing but marketing alone. It has the force of being a "standard", and while not all standards ultimately succeed, it certainly is a leg up on other options. And again, I'm not closed-minded about it... there may come a day when I look back on everything bad I've ever said about JSF and go "what in the BLUE HELL was I thinking?!?". It's hard to envision that day coming to pass, but it could. One thing I know for sure is I'm not going to get to that point based on what others tell me I should think of JSF. If I'm ever a full-blown JSF supporter it will be because I see where it solves problems that can't be solved just as good, or even better, without it. > I think the question that no-one has asked is what happens if you don't > learn and embrace JSF now and get it on your list of skills? > Even if you despise it (I have no preference yet), is it not a good move > to > get familiar with it regardless (if you can)? That's just hedging your bet, and any smart person will be doing that :) That's part of the reason I keep playing with it. Besides, you will be in a much better position to make an intelligent decision either way about it if you are familiar with it. Your opinion may change the more you learn about it too. Some people say the learning curve for JSF is less than for Struts, and I don't think I agree with that. But its a curve worth navigating in any case, just so you can decide for yourself intelligently. >>From my perspective JSF seems like it is going to become quite a large >> part > of the scene for a while until it is usurped by something greater. As > Craig > pointed out in a previous post though, as struts has, JSF might dominate > for > a good 5 years or more and be THE predominate framework that people choose > to use just as struts classic has been. Yes, it absolutely could turn out that way. Like I said in another post though, JSF isn't exactly new. So you do have to wonder, if it really was destined to be the next de facto standard in Java web development, as Struts is today, what's taking so long? On that note, JSF 2.0 *does* hold some significant promise. The original spec, from my understanding, had a fairly narrow focus. They just wanted to get the component model right, that was the primary goal. So, there are holes, or maybe more precisely weak spots, in the current spec. Shale addresses many of those areas, and the new spec rev is supposed to do the same thing. For me, I'll be interested to see what 2.0 looks like because it is at that point that JSF might actually start fulfilling some promise for me. Frank > Chris > -Original Message- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: 13 December 2005 15:17 > To: Struts Users Mailing List > Subject: Re: Is JSF ready? > > On Tue, December 13, 2005 7:27 am, Alexandre Poitras said: >> One advice, there's a lot of FUD spread around JSF right now >> so try it by yourselft first before listening to other people. > > This is perhaps the best bit of advice anyone could give. For whatever > reason, JSF has engendered a great deal of strong feelings on both sides > of the like it/love it fence. Do yourself a favor and don't even bother > with opinions at this point. Just play with it and see what you think. > > One seemingly universal truth is that if you are going to like it, chances > are it will take
RE: [OT] Re: Is JSF ready?
hi all; I'm currentyl using JSF for a project (I decided to use it because it has component model like asp.net does), I used ASP.NET before for some projects. In my opinion JSF so far away from what asp.net offers. I can't see any designer API provided (except that Sun Studio Creator). also its component model is too weak. u have type even basic html inputs if u r developing a custom component. (look at asp.net's dozen of web controls; System.Web.UI.WebControls, System.Web.UI.HtmlControls) these are my opinions about JSF Best Regards -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 6:13 PM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: Re: [OT] Re: Is JSF ready? On Tue, December 13, 2005 10:25 am, Dave Newton said: > Just out of curiosity and for the sake of completeness, what didn't you > like/etc. about it? I'm also trying to decide whether or not to bother, > as I'm tending towards much lighter-weight/more agile webapp > methodologies these days. Well, to be very honest, I can't emumerate a lot of very specific things I liked or didn't like. My current state of mind is more of a gut feeling kind of thing (which is a big part of the reason I continue to give it a chance and keep an open mind- my gut could be wrong!). That being said, there *are* a few at least somewhat specific things... * Contrary to what many people say, I don't find it to be any simpler than Struts or other frameworks I've looked at. I have to factor in the fact that I'm not a JSF expert with this next statement, but I actually find it to be somewhat *more* complex. I suspect there needs to be a differentiation between conceptual complexity and hands-on complexity though. As far as hands-on goes, what code/config you actually need to write, I haven't seen anything that makes me think its any more complex, at least not to any substantial degree. But conceptually, and probably because you need to trust the framework a little more to do more for you, I think JSF is a bit harder to get your brain around. There is a bit more "mystery", so to speak, in what JSF is doing under the covers, and if you are a person, like me, who has a tough time having all those details hidden from you, it can paradoxically be harder to understand what is actually simpler. * While this isn't a failing of JSF, it has to be factored in: there is a lack of *good* examples and documentation in my opinion. Oh, there is *plenty* of examples and documentation in general, but it seems to all be way too simplistic to be of any real help. Or it's a kitchen sink thing and you can't parse out the necessary from the fluff. Note that I'm talking about JSF in general... Shale has a lack of examples, although the documentation looks pretty good, but there are no tutorials that I'm aware of... none of this matters for Shale though because its still coming together and thus you cut it some slack. JSF as a whole though is supposed to be mature, and part of maturity in my opinion is good documentation and examples. * When your working in Struts, there are canonical answers to most questions, best-practices ways of doing things. The same is true of JSF. However, with Struts, if you want to "go off the reservation", so to speak, you can almost always do so without fighting the framework. My experience is just the opposite with JSF. If you like the "JSf Way", then you wouldn't have a problem with this, but if you like being in complete control, for me at least, its a problem. While I'm sure you *can* go off the reservation with JSF as well, it seems like much more of a fight. Some people will like the rigidity and standardization JSF can bring, and logically I can see why, but I prefer the flexibility to do it *my* way, and that doesn't seem to be a strong suite of JSF. * Hype. I generally recoil from anything that is hyped as much as JSF is, if for no other reason than I don't like being headrded around under any circumstances. Now, all those doing the hyping may well believe every single word they are saying. I certainly hope that is the case. And in the end they may well wind up being right! However, JSF is not something new. It's been around for quite a while now, and it has yet to set the world on fire. This doesn't make me right and them wrong by the way, but it *does* make you wonder if its all its cracked up to be. I see JSF as being highly desirable for corporate interests, the tool vendors and those that will sell implementations and consulting services and all that, and that worries me. I like the way Struts developed: put it out there with no motivation other than to help people, and let it develop as it will. If JSF had evolved the same way, I'd have one less worry/complaint about it, but as it stands I have to wonder what the real motivation is. Like I said, there isn't much technical points there, it's mostly psychological. However, I don't see thos
Re: Is JSF ready?
I don't agree with some of your statements. I know it is possible to implement most of JSF things using Struts but unfortunately you have to do it yourself. For exemple, to use DispatchAction for events like you suggested, you need one different method for each event or use an extra argument to determine the type of event. You may argue that it's not necessary because you just tell the button to go straight to the action. But suppose you need to support more than one type of event having the same treatment but with slight differences, you will have to distinguish the type of events. And if you want the event source, you have to be sure the request contains the necessary values, then extract them and finally interprets them yourself. All this plumbing is supported out of the box with components framework by the abstraction of user events. You don't have to care about this low level stuff. From my experience, it is quite productive. Another exemple, you want a dynamic session-scoped menu in Struts. Unless you use Struts-Menu and learn another *framework*, you need to create a new Action Form to keep all the parameters or you can deal directly with the session object. Again you have to reinvent the wheel or deal with low level stuff, wich in my main increase the risk of errors. With JSF, you just reuse an available component Nothing new to learn except the properties of the component. I don't want to start a Struts vs JSF war but I find JSF or Tapestry just more natural to use because they support higher abstractions. But nowadays C is still used because some people don't like OOP, so you can stay with Struts if you are more confortable with it. The point of my first anwser was give it a try and see if it fit you. On 12/13/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > On 12/13/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > First, it [JSF] is component oriented so it is easier to reuse > > code between applications and easier to understand. > > Struts can be easily made component-oriented. > > > Plus, the > > components are STATEFUL, they keep their state between request and > > that is a big advantage of JSF. In Struts, only the forms input > > controls were stateful and only if your form beans had session scope. > > Have JSF invented another method to keep application state? In Struts > one can use action form both for input and output, which makes it a > conversational input/output object, a view buffer, a managed bean if > you will. > > > Also, JSF provides a fine-grained event model à la Swing compare to > > the coarse-grained event model of Struts (receive request, do > > something). > > DispatchAction et al? > > > Finally, the best part of JSF comes from method and value > > binding wich allows you to use normal Java Beans for your controller > > (think of it as a Dispatch Action merged with an Action Form). > > Combining DispatchAction with ActionForm would be a simple change for > Struts, without breaking compatibility. For some reason that did not > happen [yet?]. > > > > JSF has its benefits, but the features that you quoted are not unique > for JSF. The same practices can be easily used with Struts. > > > Alexandre Poitras > > Québec, Canada > > Michael. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Is JSF ready?
I agree with you about the lack of components for the moment but things are getting better. Some commercials companies are giving their JSF implementation to Open Source Community. Oracle is already doing that with their ADF components wich are going to become a sub project of Apache MyFaces, Cherokee. Take a look at this link : http://www.orablogs.com/jjacobi/archives/001540.html Check out the Apache MyFaces Cherokee page On 12/13/05, abdurrahman sahin <[EMAIL PROTECTED]> wrote: > hi all; > > I'm currentyl using JSF for a project (I decided to use it because it has > component model like asp.net does), I used ASP.NET before for some projects. > In my opinion JSF so far away from what asp.net offers. I can't see any > designer API provided (except that Sun Studio Creator). also its component > model is too weak. u have type even basic html inputs if u r developing a > custom component. (look at asp.net's dozen of web controls; > System.Web.UI.WebControls, System.Web.UI.HtmlControls) > > these are my opinions about JSF > Best Regards > > > > -Original Message- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 13, 2005 6:13 PM > To: Struts Users Mailing List > Cc: Struts Users Mailing List > Subject: Re: [OT] Re: Is JSF ready? > > > On Tue, December 13, 2005 10:25 am, Dave Newton said: > > Just out of curiosity and for the sake of completeness, what didn't you > > like/etc. about it? I'm also trying to decide whether or not to bother, > > as I'm tending towards much lighter-weight/more agile webapp > > methodologies these days. > > Well, to be very honest, I can't emumerate a lot of very specific things I > liked or didn't like. My current state of mind is more of a gut feeling > kind of thing (which is a big part of the reason I continue to give it a > chance and keep an open mind- my gut could be wrong!). > > That being said, there *are* a few at least somewhat specific things... > > * Contrary to what many people say, I don't find it to be any simpler than > Struts or other frameworks I've looked at. I have to factor in the fact > that I'm not a JSF expert with this next statement, but I actually find it > to be somewhat *more* complex. I suspect there needs to be a > differentiation between conceptual complexity and hands-on complexity > though. As far as hands-on goes, what code/config you actually need to > write, I haven't seen anything that makes me think its any more complex, > at least not to any substantial degree. But conceptually, and probably > because you need to trust the framework a little more to do more for you, > I think JSF is a bit harder to get your brain around. There is a bit more > "mystery", so to speak, in what JSF is doing under the covers, and if you > are a person, like me, who has a tough time having all those details > hidden from you, it can paradoxically be harder to understand what is > actually simpler. > > * While this isn't a failing of JSF, it has to be factored in: there is a > lack of *good* examples and documentation in my opinion. Oh, there is > *plenty* of examples and documentation in general, but it seems to all be > way too simplistic to be of any real help. Or it's a kitchen sink thing > and you can't parse out the necessary from the fluff. Note that I'm > talking about JSF in general... Shale has a lack of examples, although the > documentation looks pretty good, but there are no tutorials that I'm aware > of... none of this matters for Shale though because its still coming > together and thus you cut it some slack. JSF as a whole though is > supposed to be mature, and part of maturity in my opinion is good > documentation and examples. > > * When your working in Struts, there are canonical answers to most > questions, best-practices ways of doing things. The same is true of JSF. > However, with Struts, if you want to "go off the reservation", so to > speak, you can almost always do so without fighting the framework. My > experience is just the opposite with JSF. If you like the "JSf Way", then > you wouldn't have a problem with this, but if you like being in complete > control, for me at least, its a problem. While I'm sure you *can* go off > the reservation with JSF as well, it seems like much more of a fight. > Some people will like the rigidity and standardization JSF can bring, and > logically I can see why, but I prefer the flexibility to do it *my* way, > and that doesn't seem to be a strong suite of JSF. > > * Hype. I generally recoil from anything that is hyped as much as JSF is, > if for no other reason than I don't like being headrded around under any > circumstances. Now, all those doing the hyping may well believe every > single word they are saying. I certainly hope that is the case. And in > the end they may well wind up being right! However, JSF is not something > new. It's been around for quite a while now, and it has yet to set the > world on fire. This doesn't make me right and th
Re: Struts DTD - basic question
Well, I use MyEclipse IDE and "XML catalog" is in specific settings for MyEclipse. So you have to serach for "XML catalog" in your libary and then add the key-String and local DTD-location there. Then your IDE will first check for local copy of DTD and only if it's not OK go to web. Lehitraot ;) Danny Rivka Shisman schrieb: Hi again and thank you all for your help Danny, I'm working with RAD (Rational Application Developer) of IBM as an IDE, and it's baseed on Eclipse. Can you please tell me where to configure the DTD locally? Thanks Rivka - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
please give me some direction
HI, How can I display some string values in combo box in jsp in my struts application. how struts dealing with combo box. please someone help me. sony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apologies - Eclipse mailing list??
Hi, aplogies for the OT post, but is anyone here on the eclipse-general or wtp mailing list? I think the signup page is blocked by the admins here, so I can't get the subscribe address, and I'm wondering if any of you guys could mail it to me off-list? Cheers, -Josh -- "His comrades fought beside him, Van Owen and the rest... But of all the thompson gunners- Roland was the best." Josh McDonald Analyst Programmer Information Technology Ph: 61 7 3006 6460 Email: [EMAIL PROTECTED] *** Messages included in this e-mail and any of its attachments are those of the author unless specifically stated to represent WorkCover Queensland. The contents of this message are to be used for the intended purpose only and are to be kept confidential at all times. This message may contain privileged information directed only to the intended addressee/s. Accidental receipt of this information should be deleted promptly and the sender notified. This e-mail has been scanned by Sophos for known viruses. However, no warranty nor liability is implied in this respect. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forcing relative urls from struts instead of the absolute urls!
Note that Struts isn't writing absolute URLs. As a webapp developer, you use "context-relative references" that Struts turns into "site-root relative" URLs. Here are examples of each type of reference, just so we are all on the same page: Relative: foo.html Site-root relative: /myapp/foo.html (And the special case of context-relative /foo.html inside an app, which then becomes /myapp/foo.html if you deploy this app with a /myapp context path.) Absolute: http://server.com/bar.html It sounds like your main challenge is that you have requests to a web server that look like http://web.domain.com/foo/bar/me mapped to an app deployed on an app server that you might access directly as http://app.domain.com/me. The app will make site-root relative URLs like /me/foo.html, and the browser will them make a request to the web server like http://web.domain.com/me/foo.html which is not what you want. What is stopping you from deploying the app with a "/foo/bar/me" context, so that it matches the "public" context on the web server? This is almost certainly the easiest solution if you can do it. Alternately, perhaps there is some proxy configuration magic that would work. To be robust, you'd probably need to use a connector (e.g. mod_jk) rather than just using a "dumb" proxy to forward requests, because I think the app server really needs to know the desired context path in order to render the pages with the proper URLs. (The alternative of filtering the response stream after-the-fact in hopes of converting all URLs is a lousy design for many reasons and not an approach I would recommend.) Using context-relative references is really useful. Actions have the same name (path) no matter what page you are working on. Images are always "/img/..." (or whatever) without having to think twice what the request URL was that caused the JSP you are editing to execute (note that the request may not match the JSP file path). And you can choose (and change) the context path at deployment time without breaking anything. However, if you are dead set on using strictly relative references, you may still be able to get it to work. I am pretty sure I have seen work, for instance. Why don't you post a specific example of something that isn't working for you. -Max On Mon, 2005-12-12 at 13:52 -0500, Michael P. Soulier wrote: > Laurie Harper wrote: > > Because if they were relative Struts would have no way to know what they > > were relative *to*? > > But why does it need to know? I have links in sites that I look after like > > foo/bar/bash.html > > If I access this via http://mybox.com/, then the browser does the right > thing. If it's accessed via http://otherbox.com/, then it still does the > right thing. That's why relative links are always recommended. > > Why does Struts need to know? This seems like another case of a > shortsighted framework to me, complicating something that would be dead > simple if we were simply generating our own html. > > > Maybe inputPattern and/or pagePattern are what you're looking for? > > > > http://struts.apache.org/struts-doc-1.2.7/userGuide/configuration.html#controller_config > > > > Maybe. I'll look at this, and thank you. > > Please pardon my exasperation. > > Mike > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is JSF ready?
> I don't know what the future will hold. JSF may win the day on nothing > but marketing alone. It has the force of being a "standard", and while > not all standards ultimately succeed, it certainly is a leg up on other I would argue that with Java (J2EE specifically) "standards" have largely just "emerged". Think of all the examples. Tomcat Ant Struts JUnit Hibernate That's, by and large, the "standard" J2EE toolkit. And by that I mean that while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a certain concensus out there and the tools in the first list are what have the mindshare now. So my point of interest is this. JSF, from what I'm seeing here (especially when the actual developers of Struts talk about their reasons for jumping to JSF) and reading elsewhere is actually succeeding IN SPITE of the fact that it's not sitting in the OpenSource non-standard seat, as Tapestry is. I find this interesting. It was bound to happen eventually, that one of Sun's reference implementations would actually become a standard. I know, EJB is a standard. But look how many people have been abandoning that in favor of more lightweight solutions, once those solutions presented themselves. So I think the fact that JSF is getting traction IN SPITE of the fact that it isn't quite as open, hasn't been open sourced as long as Tapestry, etc. is a testament to the fact that developers appear to like it. I just wanted to know (and you all have been immensely helpful in this respect) if you could get done with it, what you can with Struts. Thus the question wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" And that is the question for me. I know what I can and can't do in Struts. I've been programming with it for 5 years. I know its power and I also know I've been involved with some amazingly convoluted hacks to make it do what we needed. A framework that handles more of the request/response plumbing for me is welcome. A framework where *maybe* I can use tools that are WYSIWYG if I want is appealling after 5 years of hand-coding XML descriptor files that are gigantic. A framework that handles requests and responses and doesn't push as far back into the business tier is welcome to me. So I like the idea of JSF. Just like I like the idea of Tapestry and even Ruby on Rails. I just wanted to know if you could write a JSF app today and be reasonably sure that you could do easy validation on the server, be relatively efficient in it and not run into major snafus with application server differences. Preston - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
I think JSF will succeed because it was not designed by experts in a meeting room. They looked at what was already available (Tapestry, Struts, ASP.net) and took inspiration of it. EJB3 is going the same way by looking at Spring and Hibernate. I think the JEE world learned is lesson : let the open source organisationand private corporations experiment new things then standardize an API based on the existant code, so people can avoid any vendor lock-in and it allows more then one implementation of the same API. On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > I don't know what the future will hold. JSF may win the day on nothing > > but marketing alone. It has the force of being a "standard", and while > > not all standards ultimately succeed, it certainly is a leg up on other > > I would argue that with Java (J2EE specifically) "standards" have largely > just "emerged". Think of all the examples. > > Tomcat > Ant > Struts > JUnit > Hibernate > > That's, by and large, the "standard" J2EE toolkit. And by that I mean that > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a certain > concensus out there and the tools in the first list are what have the > mindshare now. > > So my point of interest is this. JSF, from what I'm seeing here > (especially when the actual developers of Struts talk about their reasons > for jumping to JSF) and reading elsewhere is actually succeeding IN SPITE > of the fact that it's not sitting in the OpenSource non-standard seat, as > Tapestry is. I find this interesting. It was bound to happen eventually, > that one of Sun's reference implementations would actually become a > standard. I know, EJB is a standard. But look how many people have been > abandoning that in favor of more lightweight solutions, once those > solutions presented themselves. > > So I think the fact that JSF is getting traction IN SPITE of the fact that > it isn't quite as open, hasn't been open sourced as long as Tapestry, etc. > is a testament to the fact that developers appear to like it. I just > wanted to know (and you all have been immensely helpful in this respect) > if you could get done with it, what you can with Struts. Thus the question > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > And that is the question for me. I know what I can and can't do in Struts. > I've been programming with it for 5 years. I know its power and I also > know I've been involved with some amazingly convoluted hacks to make it do > what we needed. A framework that handles more of the request/response > plumbing for me is welcome. A framework where *maybe* I can use tools that > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > descriptor files that are gigantic. A framework that handles requests and > responses and doesn't push as far back into the business tier is welcome > to me. > > So I like the idea of JSF. Just like I like the idea of Tapestry and even > Ruby on Rails. I just wanted to know if you could write a JSF app today > and be reasonably sure that you could do easy validation on the server, be > relatively efficient in it and not run into major snafus with application > server differences. > > Preston > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Cookie
Hi!! I am not geting any help from net about this issue. So, postin this question on this group. I want to know exactly what difference does it make if i set Cookie.setSecure(true)?? I am using SSL in my application. What are the advantages or disadvantages of doing it from security point of view. Please help Deepa
Re: [OT] Cookie
If you set this property to true, your cookie will be sent over an HTTP/SSL (https) connection. What it means is that every value to be stored in this cookie are encrypted before being sent on the network. This way, any malicious third party who are *sniffing* the network can't read the values to be stored in this cookie. You should only use it if you store sensible information in the cookie that you don't want anyone to intercept. But be warned that the cookie can still be accessed by the client, so it isn't the best place to store password unless you use encrypted values. Cookie.setSecure() only encrypt data sent on the network wich are decrypted by the client when they are received. It doesn't encrypt the values stored on the client. You have to do it yourself. On 12/13/05, Deepa Khetan <[EMAIL PROTECTED]> wrote: > Hi!! > I am not geting any help from net about this issue. So, postin this question > on this group. > I want to know exactly what difference does it make if i set > Cookie.setSecure(true)?? I am using SSL in my application. What are the > advantages or disadvantages of doing it from security point of view. > > Please help > > Deepa > > -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cookie
If you setSecure(true), the cookie will ONLY be available through HTTPS. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
I don't think it is accurate to say that "Struts is embracing JSF". More accurate, probably, would be that Struts tolerates JSF because Craig's career is presently tied to JSF. That's okay with me and nobody in particular cares whether I like or or not, but that is not an endorsement so much as a sop. JSF has been around forever, by the way. Tapestry is superior, in my opinion. On 12/12/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > I'm starting to begin looking at JSF in part because of what I've read > here on the Struts mailing list. i.e. Struts is embracing JSF, many > developers see it as inevitable. I have some experience with Tapestry and > Ruby on Rails so I'm excited about component frameworks. However, what I > don't know, having just started learning JSF is how ready it is. I can't > take wars developed in Java Studio Creator and deploy them to WebSphere > (we use WebSpere where I work) and I'm not sure how it stacks up to Struts > in terms of input validation, ease of integration with a business tier and > Hibernate and other common J2EE issues. Can anyone with experience give me > an idea if now is the time to jump in the water? > > The reason I ask here is because of the nature of Struts creating new > projects to extend and enhance the JSF API. I don't know (with that in > mind) if that's sign of JSF not being fully baked, or not being up to > par with what most Struts users are used to. > > This is one of those situations where I want to pick the right horse. My > experience has been that usually the open source solution is the better > solution. See Ant, Struts, Spring, Hibernate, Tomcat as examples. So > because of licensing and who created the reference implementation I'm > naturally a little skeptical of JSF. Excited, but skeptical. Hopefully > someone can fill me in or at least explain what holes Shale is meant to > fill. > > Preston > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Is JSF ready?
If your opinion is correct, Chris, why after all these years is JSF still in its infancy? This has been the slowest gestation in the history of software. On 12/13/05, Chris McCormack <[EMAIL PROTECTED]> wrote: > > Frank - > When JSF matures and you have looked over it again a few times, but > possibly > still not had your epiphany. Would you remain happy with the technologies > you know now to see you through the seemingly Shale/JSF dominated future > of > Java web frameworks? > > I think the question that no-one has asked is what happens if you don't > learn and embrace JSF now and get it on your list of skills? > Even if you despise it (I have no preference yet), is it not a good move > to > get familiar with it regardless (if you can)? > From my perspective JSF seems like it is going to become quite a large > part > of the scene for a while until it is usurped by something greater. As > Craig > pointed out in a previous post though, as struts has, JSF might dominate > for > a good 5 years or more and be THE predominate framework that people choose > to use just as struts classic has been. > > Chris > -Original Message- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: 13 December 2005 15:17 > To: Struts Users Mailing List > Subject: Re: Is JSF ready? > > On Tue, December 13, 2005 7:27 am, Alexandre Poitras said: > > One advice, there's a lot of FUD spread around JSF right now > > so try it by yourselft first before listening to other people. > > This is perhaps the best bit of advice anyone could give. For whatever > reason, JSF has engendered a great deal of strong feelings on both sides > of the like it/love it fence. Do yourself a favor and don't even bother > with opinions at this point. Just play with it and see what you think. > > One seemingly universal truth is that if you are going to like it, chances > are it will take a little while. I haven't talked to many people that > instantly loved it, but I have spoken to numerous people who didn't like > it at first and gradually they came to like it a great deal. So give it a > fair shake before you decide. > > If you really want another opinion for your tally sheet, put me down as > not a big fan. My JSF experiences have not been encouraging, but notice I > said experienceS... I keep going back and giving it another shot, hoping > the epiphany that many people seem to have will hit me too. It hasn't yet > though. It seems that for everything I see that is good about it, I find > something that I think is bad, so on balance I remain unconvinced. > > But, my opinion is no better than anyone else', so give it a try yourself, > and give it some time to grow on you, and see if it does. > > Frank > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This email originated externally and has been scanned by MessageLabs > > __ > This email has been scanned for all viruses by the MessageLabs SkyScan > service. For more information on a proactive anti-virus service working > around the clock, around the globe, visit http://www.messagelabs.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Is JSF ready?
Preston, none of those examples are J2EE. They can be used with J2EE but they have nothing to do with anything beyond J2SE. On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > I don't know what the future will hold. JSF may win the day on nothing > > but marketing alone. It has the force of being a "standard", and while > > not all standards ultimately succeed, it certainly is a leg up on other > > I would argue that with Java (J2EE specifically) "standards" have largely > just "emerged". Think of all the examples. > > Tomcat > Ant > Struts > JUnit > Hibernate > > That's, by and large, the "standard" J2EE toolkit. And by that I mean that > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a certain > concensus out there and the tools in the first list are what have the > mindshare now. > > So my point of interest is this. JSF, from what I'm seeing here > (especially when the actual developers of Struts talk about their reasons > for jumping to JSF) and reading elsewhere is actually succeeding IN SPITE > of the fact that it's not sitting in the OpenSource non-standard seat, as > Tapestry is. I find this interesting. It was bound to happen eventually, > that one of Sun's reference implementations would actually become a > standard. I know, EJB is a standard. But look how many people have been > abandoning that in favor of more lightweight solutions, once those > solutions presented themselves. > > So I think the fact that JSF is getting traction IN SPITE of the fact that > it isn't quite as open, hasn't been open sourced as long as Tapestry, etc. > is a testament to the fact that developers appear to like it. I just > wanted to know (and you all have been immensely helpful in this respect) > if you could get done with it, what you can with Struts. Thus the question > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > And that is the question for me. I know what I can and can't do in Struts. > I've been programming with it for 5 years. I know its power and I also > know I've been involved with some amazingly convoluted hacks to make it do > what we needed. A framework that handles more of the request/response > plumbing for me is welcome. A framework where *maybe* I can use tools that > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > descriptor files that are gigantic. A framework that handles requests and > responses and doesn't push as far back into the business tier is welcome > to me. > > So I like the idea of JSF. Just like I like the idea of Tapestry and even > Ruby on Rails. I just wanted to know if you could write a JSF app today > and be reasonably sure that you could do easy validation on the server, be > relatively efficient in it and not run into major snafus with application > server differences. > > Preston > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Is JSF ready?
Good Lord, Alexandre! Do you know anything about the history of JSF. On 12/13/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > I think JSF will succeed because it was not designed by experts in a > meeting room. They looked at what was already available (Tapestry, > Struts, ASP.net) and took inspiration of it. > EJB3 is going the same way by looking at Spring and Hibernate. I think > the JEE world learned is lesson : let the open source organisationand > private corporations experiment new things then standardize an API > based on the existant code, so people can avoid any vendor lock-in and > it allows more then one implementation of the same API. > > On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > I don't know what the future will hold. JSF may win the day on > nothing > > > but marketing alone. It has the force of being a "standard", and > while > > > not all standards ultimately succeed, it certainly is a leg up on > other > > > > I would argue that with Java (J2EE specifically) "standards" have > largely > > just "emerged". Think of all the examples. > > > > Tomcat > > Ant > > Struts > > JUnit > > Hibernate > > > > That's, by and large, the "standard" J2EE toolkit. And by that I mean > that > > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a > certain > > concensus out there and the tools in the first list are what have the > > mindshare now. > > > > So my point of interest is this. JSF, from what I'm seeing here > > (especially when the actual developers of Struts talk about their > reasons > > for jumping to JSF) and reading elsewhere is actually succeeding IN > SPITE > > of the fact that it's not sitting in the OpenSource non-standard seat, > as > > Tapestry is. I find this interesting. It was bound to happen eventually, > > that one of Sun's reference implementations would actually become a > > standard. I know, EJB is a standard. But look how many people have been > > abandoning that in favor of more lightweight solutions, once those > > solutions presented themselves. > > > > So I think the fact that JSF is getting traction IN SPITE of the fact > that > > it isn't quite as open, hasn't been open sourced as long as Tapestry, > etc. > > is a testament to the fact that developers appear to like it. I just > > wanted to know (and you all have been immensely helpful in this respect) > > if you could get done with it, what you can with Struts. Thus the > question > > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > > > And that is the question for me. I know what I can and can't do in > Struts. > > I've been programming with it for 5 years. I know its power and I also > > know I've been involved with some amazingly convoluted hacks to make it > do > > what we needed. A framework that handles more of the request/response > > plumbing for me is welcome. A framework where *maybe* I can use tools > that > > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > > descriptor files that are gigantic. A framework that handles requests > and > > responses and doesn't push as far back into the business tier is > welcome > > to me. > > > > So I like the idea of JSF. Just like I like the idea of Tapestry and > even > > Ruby on Rails. I just wanted to know if you could write a JSF app today > > and be reasonably sure that you could do easy validation on the server, > be > > relatively efficient in it and not run into major snafus with > application > > server differences. > > > > Preston > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Alexandre Poitras > Québec, Canada > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Is JSF ready?
Last I checked servlets / jsp were part of J2EE. -- "His comrades fought beside him, Van Owen and the rest... But of all the thompson gunners- Roland was the best." Josh McDonald Analyst Programmer Information Technology Ph: 61 7 3006 6460 Email: [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 14/12/2005 4:31:21 pm >>> Preston, none of those examples are J2EE. They can be used with J2EE but they have nothing to do with anything beyond J2SE. On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > I don't know what the future will hold. JSF may win the day on nothing > > but marketing alone. It has the force of being a "standard", and while > > not all standards ultimately succeed, it certainly is a leg up on other > > I would argue that with Java (J2EE specifically) "standards" have largely > just "emerged". Think of all the examples. > > Tomcat > Ant > Struts > JUnit > Hibernate > > That's, by and large, the "standard" J2EE toolkit. And by that I mean that > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a certain > concensus out there and the tools in the first list are what have the > mindshare now. > > So my point of interest is this. JSF, from what I'm seeing here > (especially when the actual developers of Struts talk about their reasons > for jumping to JSF) and reading elsewhere is actually succeeding IN SPITE > of the fact that it's not sitting in the OpenSource non-standard seat, as > Tapestry is. I find this interesting. It was bound to happen eventually, > that one of Sun's reference implementations would actually become a > standard. I know, EJB is a standard. But look how many people have been > abandoning that in favor of more lightweight solutions, once those > solutions presented themselves. > > So I think the fact that JSF is getting traction IN SPITE of the fact that > it isn't quite as open, hasn't been open sourced as long as Tapestry, etc. > is a testament to the fact that developers appear to like it. I just > wanted to know (and you all have been immensely helpful in this respect) > if you could get done with it, what you can with Struts. Thus the question > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > And that is the question for me. I know what I can and can't do in Struts. > I've been programming with it for 5 years. I know its power and I also > know I've been involved with some amazingly convoluted hacks to make it do > what we needed. A framework that handles more of the request/response > plumbing for me is welcome. A framework where *maybe* I can use tools that > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > descriptor files that are gigantic. A framework that handles requests and > responses and doesn't push as far back into the business tier is welcome > to me. > > So I like the idea of JSF. Just like I like the idea of Tapestry and even > Ruby on Rails. I just wanted to know if you could write a JSF app today > and be reasonably sure that you could do easy validation on the server, be > relatively efficient in it and not run into major snafus with application > server differences. > > Preston > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ *** Messages included in this e-mail and any of its attachments are those of the author unless specifically stated to represent WorkCover Queensland. The contents of this message are to be used for the intended purpose only and are to be kept confidential at all times. This message may contain privileged information directed only to the intended addressee/s. Accidental receipt of this information should be deleted promptly and the sender notified. This e-mail has been scanned by Sophos for known viruses. However, no warranty nor liability is implied in this respect. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
And, Josh, last time I looked JSP was not on the list we are talking about. So, what was your point? On 12/13/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > Last I checked servlets / jsp were part of J2EE. > > -- > > "His comrades fought beside him, Van Owen and the rest... >But of all the thompson gunners- Roland was the best." > > Josh McDonald > Analyst Programmer > Information Technology > Ph: 61 7 3006 6460 > Email: [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 14/12/2005 4:31:21 pm >>> > Preston, none of those examples are J2EE. They can be used with J2EE > but > they have nothing to do with anything beyond J2SE. > > > On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > > > I don't know what the future will hold. JSF may win the day on > nothing > > > but marketing alone. It has the force of being a "standard", and > while > > > not all standards ultimately succeed, it certainly is a leg up on > other > > > > I would argue that with Java (J2EE specifically) "standards" have > largely > > just "emerged". Think of all the examples. > > > > Tomcat > > Ant > > Struts > > JUnit > > Hibernate > > > > That's, by and large, the "standard" J2EE toolkit. And by that I mean > that > > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a > certain > > concensus out there and the tools in the first list are what have > the > > mindshare now. > > > > So my point of interest is this. JSF, from what I'm seeing here > > (especially when the actual developers of Struts talk about their > reasons > > for jumping to JSF) and reading elsewhere is actually succeeding IN > SPITE > > of the fact that it's not sitting in the OpenSource non-standard > seat, as > > Tapestry is. I find this interesting. It was bound to happen > eventually, > > that one of Sun's reference implementations would actually become a > > standard. I know, EJB is a standard. But look how many people have > been > > abandoning that in favor of more lightweight solutions, once those > > solutions presented themselves. > > > > So I think the fact that JSF is getting traction IN SPITE of the fact > that > > it isn't quite as open, hasn't been open sourced as long as Tapestry, > etc. > > is a testament to the fact that developers appear to like it. I just > > wanted to know (and you all have been immensely helpful in this > respect) > > if you could get done with it, what you can with Struts. Thus the > question > > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > > > And that is the question for me. I know what I can and can't do in > Struts. > > I've been programming with it for 5 years. I know its power and I > also > > know I've been involved with some amazingly convoluted hacks to make > it do > > what we needed. A framework that handles more of the > request/response > > plumbing for me is welcome. A framework where *maybe* I can use tools > that > > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > > descriptor files that are gigantic. A framework that handles requests > and > > responses and doesn't push as far back into the business tier is > welcome > > to me. > > > > So I like the idea of JSF. Just like I like the idea of Tapestry and > even > > Ruby on Rails. I just wanted to know if you could write a JSF app > today > > and be reasonably sure that you could do easy validation on the > server, be > > relatively efficient in it and not run into major snafus with > application > > server differences. > > > > Preston > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its > back." > ~Dakota Jack~ > > > > > > > > *** > Messages included in this e-mail and any of its attachments are those > of the author unless specifically stated to represent WorkCover > Queensland. The contents of this message are to be used for the intended > purpose only and are to be kept confidential at all times. > This message may contain privileged information directed only to the > intended addressee/s. Accidental receipt of this information should be > deleted promptly and the sender notified. > This e-mail has been scanned by Sophos for known viruses. > However, no warranty nor liability is implied in this respect. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Is JSF ready?
Mainly I thought I'd interrupt the ranting :) And what's tomcat if it's not an implementation of JSP / Servlets, and hence a partial implementation of J2EE? -- "His comrades fought beside him, Van Owen and the rest... But of all the thompson gunners- Roland was the best." Josh McDonald Analyst Programmer Information Technology Ph: 61 7 3006 6460 Email: [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 14/12/2005 4:38:20 pm >>> And, Josh, last time I looked JSP was not on the list we are talking about. So, what was your point? On 12/13/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > Last I checked servlets / jsp were part of J2EE. > > -- > > "His comrades fought beside him, Van Owen and the rest... >But of all the thompson gunners- Roland was the best." > > Josh McDonald > Analyst Programmer > Information Technology > Ph: 61 7 3006 6460 > Email: [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 14/12/2005 4:31:21 pm >>> > Preston, none of those examples are J2EE. They can be used with J2EE > but > they have nothing to do with anything beyond J2SE. > > > On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > > > I don't know what the future will hold. JSF may win the day on > nothing > > > but marketing alone. It has the force of being a "standard", and > while > > > not all standards ultimately succeed, it certainly is a leg up on > other > > > > I would argue that with Java (J2EE specifically) "standards" have > largely > > just "emerged". Think of all the examples. > > > > Tomcat > > Ant > > Struts > > JUnit > > Hibernate > > > > That's, by and large, the "standard" J2EE toolkit. And by that I mean > that > > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a > certain > > concensus out there and the tools in the first list are what have > the > > mindshare now. > > > > So my point of interest is this. JSF, from what I'm seeing here > > (especially when the actual developers of Struts talk about their > reasons > > for jumping to JSF) and reading elsewhere is actually succeeding IN > SPITE > > of the fact that it's not sitting in the OpenSource non-standard > seat, as > > Tapestry is. I find this interesting. It was bound to happen > eventually, > > that one of Sun's reference implementations would actually become a > > standard. I know, EJB is a standard. But look how many people have > been > > abandoning that in favor of more lightweight solutions, once those > > solutions presented themselves. > > > > So I think the fact that JSF is getting traction IN SPITE of the fact > that > > it isn't quite as open, hasn't been open sourced as long as Tapestry, > etc. > > is a testament to the fact that developers appear to like it. I just > > wanted to know (and you all have been immensely helpful in this > respect) > > if you could get done with it, what you can with Struts. Thus the > question > > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > > > And that is the question for me. I know what I can and can't do in > Struts. > > I've been programming with it for 5 years. I know its power and I > also > > know I've been involved with some amazingly convoluted hacks to make > it do > > what we needed. A framework that handles more of the > request/response > > plumbing for me is welcome. A framework where *maybe* I can use tools > that > > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > > descriptor files that are gigantic. A framework that handles requests > and > > responses and doesn't push as far back into the business tier is > welcome > > to me. > > > > So I like the idea of JSF. Just like I like the idea of Tapestry and > even > > Ruby on Rails. I just wanted to know if you could write a JSF app > today > > and be reasonably sure that you could do easy validation on the > server, be > > relatively efficient in it and not run into major snafus with > application > > server differences. > > > > Preston > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its > back." > ~Dakota Jack~ > > > > > > > > *** > Messages included in this e-mail and any of its attachments are those > of the author unless specifically stated to represent WorkCover > Queensland. The contents of this message are to be used for the intended > purpose only and are to be kept confidential at all times. > This message may contain privileged information directed only to the > intended addressee/s. Accidental receipt of this information should be > deleted promptly and the sender notified. > This e-mail has been scanned by Sophos for known viruses. > However, no warranty nor liability is implied in this respect. > >
Re: Is JSF ready?
Just in case you are having difficulty with seeing the list, Josh, here it is: > I would argue that with Java (J2EE specifically) "standards" have largely > just "emerged". Think of all the examples. > > Tomcat > Ant > Struts > JUnit > Hibernate > > That's, by and large, the "standard" J2EE toolkit. There you have it. See? No servlets! No JSP! Good to go now? Would you endorse this statement that this list constitutes the "'standard' J2EE toolkit"? Also, one might note that J2EE is a framework and not a toolkit. Ted Husted often treats these two things alike and so often starts thinking of frameworks as just another part of an application, but that does not mean it is a good thing to think. The GoF are good on this distinction. On 12/13/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > Last I checked servlets / jsp were part of J2EE. > > -- > > "His comrades fought beside him, Van Owen and the rest... >But of all the thompson gunners- Roland was the best." > > Josh McDonald > Analyst Programmer > Information Technology > Ph: 61 7 3006 6460 > Email: [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 14/12/2005 4:31:21 pm >>> > Preston, none of those examples are J2EE. They can be used with J2EE > but > they have nothing to do with anything beyond J2SE. > > > On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > > > I don't know what the future will hold. JSF may win the day on > nothing > > > but marketing alone. It has the force of being a "standard", and > while > > > not all standards ultimately succeed, it certainly is a leg up on > other > > > > I would argue that with Java (J2EE specifically) "standards" have > largely > > just "emerged". Think of all the examples. > > > > Tomcat > > Ant > > Struts > > JUnit > > Hibernate > > > > That's, by and large, the "standard" J2EE toolkit. And by that I mean > that > > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a > certain > > concensus out there and the tools in the first list are what have > the > > mindshare now. > > > > So my point of interest is this. JSF, from what I'm seeing here > > (especially when the actual developers of Struts talk about their > reasons > > for jumping to JSF) and reading elsewhere is actually succeeding IN > SPITE > > of the fact that it's not sitting in the OpenSource non-standard > seat, as > > Tapestry is. I find this interesting. It was bound to happen > eventually, > > that one of Sun's reference implementations would actually become a > > standard. I know, EJB is a standard. But look how many people have > been > > abandoning that in favor of more lightweight solutions, once those > > solutions presented themselves. > > > > So I think the fact that JSF is getting traction IN SPITE of the fact > that > > it isn't quite as open, hasn't been open sourced as long as Tapestry, > etc. > > is a testament to the fact that developers appear to like it. I just > > wanted to know (and you all have been immensely helpful in this > respect) > > if you could get done with it, what you can with Struts. Thus the > question > > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > > > And that is the question for me. I know what I can and can't do in > Struts. > > I've been programming with it for 5 years. I know its power and I > also > > know I've been involved with some amazingly convoluted hacks to make > it do > > what we needed. A framework that handles more of the > request/response > > plumbing for me is welcome. A framework where *maybe* I can use tools > that > > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > > descriptor files that are gigantic. A framework that handles requests > and > > responses and doesn't push as far back into the business tier is > welcome > > to me. > > > > So I like the idea of JSF. Just like I like the idea of Tapestry and > even > > Ruby on Rails. I just wanted to know if you could write a JSF app > today > > and be reasonably sure that you could do easy validation on the > server, be > > relatively efficient in it and not run into major snafus with > application > > server differences. > > > > Preston > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its > back." > ~Dakota Jack~ > > > > > > > > *** > Messages included in this e-mail and any of its attachments are those > of the author unless specifically stated to represent WorkCover > Queensland. The contents of this message are to be used for the intended > purpose only and are to be kept confidential at all times. > This message may contain privileged information directed only to the > intended addressee/s. Accidental receipt of this information should be > deleted promptly
Re: Is JSF ready?
You make a point pretending to give us light and now you claim to only be interested in heat. I guess when you say something mistaken the best way to cover it is with an attack. Good show! I don't think talk about substance is ranting, personally. But, with you who knows. You may next say you were only using "ranting" as a jumbled "grantin". You are a slippery one alright. On 12/13/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > Mainly I thought I'd interrupt the ranting :) > > And what's tomcat if it's not an implementation of JSP / Servlets, and > hence a partial implementation of J2EE? > > -- > > "His comrades fought beside him, Van Owen and the rest... >But of all the thompson gunners- Roland was the best." > > Josh McDonald > Analyst Programmer > Information Technology > Ph: 61 7 3006 6460 > Email: [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 14/12/2005 4:38:20 pm >>> > And, Josh, last time I looked JSP was not on the list we are talking > about. > So, what was your point? > > On 12/13/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > > > Last I checked servlets / jsp were part of J2EE. > > > > -- > > > > "His comrades fought beside him, Van Owen and the rest... > >But of all the thompson gunners- Roland was the best." > > > > Josh McDonald > > Analyst Programmer > > Information Technology > > Ph: 61 7 3006 6460 > > Email: [EMAIL PROTECTED] > > > > > > >>> [EMAIL PROTECTED] 14/12/2005 4:31:21 pm >>> > > Preston, none of those examples are J2EE. They can be used with > J2EE > > but > > they have nothing to do with anything beyond J2SE. > > > > > > On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > > > > > I don't know what the future will hold. JSF may win the day on > > nothing > > > > but marketing alone. It has the force of being a "standard", > and > > while > > > > not all standards ultimately succeed, it certainly is a leg up > on > > other > > > > > > I would argue that with Java (J2EE specifically) "standards" have > > largely > > > just "emerged". Think of all the examples. > > > > > > Tomcat > > > Ant > > > Struts > > > JUnit > > > Hibernate > > > > > > That's, by and large, the "standard" J2EE toolkit. And by that I > mean > > that > > > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a > > certain > > > concensus out there and the tools in the first list are what have > > the > > > mindshare now. > > > > > > So my point of interest is this. JSF, from what I'm seeing here > > > (especially when the actual developers of Struts talk about their > > reasons > > > for jumping to JSF) and reading elsewhere is actually succeeding > IN > > SPITE > > > of the fact that it's not sitting in the OpenSource non-standard > > seat, as > > > Tapestry is. I find this interesting. It was bound to happen > > eventually, > > > that one of Sun's reference implementations would actually become > a > > > standard. I know, EJB is a standard. But look how many people have > > been > > > abandoning that in favor of more lightweight solutions, once those > > > solutions presented themselves. > > > > > > So I think the fact that JSF is getting traction IN SPITE of the > fact > > that > > > it isn't quite as open, hasn't been open sourced as long as > Tapestry, > > etc. > > > is a testament to the fact that developers appear to like it. I > just > > > wanted to know (and you all have been immensely helpful in this > > respect) > > > if you could get done with it, what you can with Struts. Thus the > > question > > > wasn't "Is JSF better than Struts?" The question was "Is JSF > ready?" > > > > > > And that is the question for me. I know what I can and can't do in > > Struts. > > > I've been programming with it for 5 years. I know its power and I > > also > > > know I've been involved with some amazingly convoluted hacks to > make > > it do > > > what we needed. A framework that handles more of the > > request/response > > > plumbing for me is welcome. A framework where *maybe* I can use > tools > > that > > > are WYSIWYG if I want is appealling after 5 years of hand-coding > XML > > > descriptor files that are gigantic. A framework that handles > requests > > and > > > responses and doesn't push as far back into the business tier is > > welcome > > > to me. > > > > > > So I like the idea of JSF. Just like I like the idea of Tapestry > and > > even > > > Ruby on Rails. I just wanted to know if you could write a JSF app > > today > > > and be reasonably sure that you could do easy validation on the > > server, be > > > relatively efficient in it and not run into major snafus with > > application > > > server differences. > > > > > > Preston > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > > back." > > ~Dakota Jack~ > >
Re: Is JSF ready?
By the way, do you really think Tomcat is really "an implementation of JSP / Servlets" and "hence a partial implementation of J2EE"? You throw the word "implementation" around like a first semester student at a second rate community college. You cannot use words every which way you want and do so properly, you know. I would strongly suggest you look at Tomcat code and see what really is there. You might find it fascinating, if you are not to busy walking backwards. By the way, did anyone know what Bo Jangles holds the world record in running the 100 yard dash backwards? I don't know what made me think of that. Interesting though! No? On 12/13/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > Mainly I thought I'd interrupt the ranting :) > > And what's tomcat if it's not an implementation of JSP / Servlets, and > hence a partial implementation of J2EE? > > -- > > "His comrades fought beside him, Van Owen and the rest... >But of all the thompson gunners- Roland was the best." > > Josh McDonald > Analyst Programmer > Information Technology > Ph: 61 7 3006 6460 > Email: [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 14/12/2005 4:38:20 pm >>> > And, Josh, last time I looked JSP was not on the list we are talking > about. > So, what was your point? > > On 12/13/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > > > Last I checked servlets / jsp were part of J2EE. > > > > -- > > > > "His comrades fought beside him, Van Owen and the rest... > >But of all the thompson gunners- Roland was the best." > > > > Josh McDonald > > Analyst Programmer > > Information Technology > > Ph: 61 7 3006 6460 > > Email: [EMAIL PROTECTED] > > > > > > >>> [EMAIL PROTECTED] 14/12/2005 4:31:21 pm >>> > > Preston, none of those examples are J2EE. They can be used with > J2EE > > but > > they have nothing to do with anything beyond J2SE. > > > > > > On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > > > > > I don't know what the future will hold. JSF may win the day on > > nothing > > > > but marketing alone. It has the force of being a "standard", > and > > while > > > > not all standards ultimately succeed, it certainly is a leg up > on > > other > > > > > > I would argue that with Java (J2EE specifically) "standards" have > > largely > > > just "emerged". Think of all the examples. > > > > > > Tomcat > > > Ant > > > Struts > > > JUnit > > > Hibernate > > > > > > That's, by and large, the "standard" J2EE toolkit. And by that I > mean > > that > > > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a > > certain > > > concensus out there and the tools in the first list are what have > > the > > > mindshare now. > > > > > > So my point of interest is this. JSF, from what I'm seeing here > > > (especially when the actual developers of Struts talk about their > > reasons > > > for jumping to JSF) and reading elsewhere is actually succeeding > IN > > SPITE > > > of the fact that it's not sitting in the OpenSource non-standard > > seat, as > > > Tapestry is. I find this interesting. It was bound to happen > > eventually, > > > that one of Sun's reference implementations would actually become > a > > > standard. I know, EJB is a standard. But look how many people have > > been > > > abandoning that in favor of more lightweight solutions, once those > > > solutions presented themselves. > > > > > > So I think the fact that JSF is getting traction IN SPITE of the > fact > > that > > > it isn't quite as open, hasn't been open sourced as long as > Tapestry, > > etc. > > > is a testament to the fact that developers appear to like it. I > just > > > wanted to know (and you all have been immensely helpful in this > > respect) > > > if you could get done with it, what you can with Struts. Thus the > > question > > > wasn't "Is JSF better than Struts?" The question was "Is JSF > ready?" > > > > > > And that is the question for me. I know what I can and can't do in > > Struts. > > > I've been programming with it for 5 years. I know its power and I > > also > > > know I've been involved with some amazingly convoluted hacks to > make > > it do > > > what we needed. A framework that handles more of the > > request/response > > > plumbing for me is welcome. A framework where *maybe* I can use > tools > > that > > > are WYSIWYG if I want is appealling after 5 years of hand-coding > XML > > > descriptor files that are gigantic. A framework that handles > requests > > and > > > responses and doesn't push as far back into the business tier is > > welcome > > > to me. > > > > > > So I like the idea of JSF. Just like I like the idea of Tapestry > and > > even > > > Ruby on Rails. I just wanted to know if you could write a JSF app > > today > > > and be reasonably sure that you could do easy validation on the > > server, be > > > relatively efficient in it and not run into major snafus with > > application > > > server differences. > > > > > > Preston > > > > > > > > > > > > -
Re: Noob question...
The "culprit", Josh, I would guess, would be an argumetn type mismatch during an invocation of PropertyUtils. This means, usually, that you are not using the multiple select tag in Struts properly. This is an old problem easy to diagnos both from the list and from google. Checking out these sources on an unusual area is usually better than striking out at random on the list. On 12/12/05, Josh McDonald <[EMAIL PROTECTED]> wrote: > > Thanks, managed to get it working by re-writing a gang of code, so not > sure what exactly was the culprit :| > > -Josh > > -- > > "His comrades fought beside him, Van Owen and the rest... >But of all the thompson gunners- Roland was the best." > > Josh McDonald > Analyst Programmer > Information Technology > Ph: 61 7 3006 6460 > Email: [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 13/12/2005 12:43:20 pm >>> > "Josh McDonald" <[EMAIL PROTECTED]> wrote on 12/12/2005 > > 06:26:33 PM: > > > Bit of a noob to debugging struts apps, what exactly does "Failed to > > obtain specified collection" mean? I can't find anything on google > that > > explains it. I've gone over the JSP code and various actions and > forms > > etc, and can't see anything wrong, and the code is copied from > another > > jsp that's simply dealing with a similar action/form. > > Hi Josh, not really sure since you haven't posted any code, but > (assuming > your error occurs while displaying your jsp) perhaps your jsp is trying > to > display a collection of objects which is perhaps declared in your form > > bean and populated in your action but maybe it can't since you forgot > to > add a getter for the collection...? > > If this doesn'rt help, post some code from the offending jsp - > especially > the parts of the jsp that is dealing with any kind of collection of > objects.. > > Sorry if this is very vague - but hope it helps anyways.:) > > > > > "His comrades fought beside him, Van Owen and the rest... > >But of all the thompson gunners- Roland was the best." > > > > Josh McDonald > > Regards, > Geeta > > > > > > > > *** > Messages included in this e-mail and any of its attachments are those > of the author unless specifically stated to represent WorkCover > Queensland. The contents of this message are to be used for the intended > purpose only and are to be kept confidential at all times. > This message may contain privileged information directed only to the > intended addressee/s. Accidental receipt of this information should be > deleted promptly and the sender notified. > This e-mail has been scanned by Sophos for known viruses. > However, no warranty nor liability is implied in this respect. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Is JSF ready?
On Tue, 13 Dec 2005, Dakota Jack wrote: Preston, none of those examples are J2EE. They can be used with J2EE but they have nothing to do with anything beyond J2SE. Toolkit. As in the tools one uses to build J2EE apps. Pedantic much... Preston - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
On Tue, 13 Dec 2005, Dakota Jack wrote: And, Josh, last time I looked JSP was not on the list we are talking about. So, what was your point? The point is you're being pedantic. I wasn't describing the entirety of J2EE or even the implementation. Rather the tools, frameworks, etc. used to build J2EE apps. Preston - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is JSF ready?
On Wed, 14 Dec 2005, Josh McDonald wrote: Mainly I thought I'd interrupt the ranting :) And what's tomcat if it's not an implementation of JSP / Servlets, and hence a partial implementation of J2EE? Just ignore him. He doesn't care to be helpful. Just wants to hear himself speak. Preston - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
