Re: contrib/struts-shale-mailreader
Struts User wrote: Having said all this, the framework is powerful for sophisticated web production side, where all fragments of each page are completely dynamic based on built-in backend intelligence. Tiles is appropriate for such page, rather than each page need a backing bean. Hi Batien, I am running the struts-shale-mailreader and just started to look into Java Server Faces and Shale. Thus, I am not totally familiar with the new frameworks and hope you can bear with me. Are you saying that Tile and backing bean don't have to co-exist? I thought Tiles and backing bean are two different things. Backing bean is sort of like ActionForm in Struts. More accurately, backing bean is like OzPage in Tak's introductory document. Backing beans and tiles need to co-exist in any decent dynamic web or portlet application. This is a very powerful presentation framework. Backing bean is a power tool under jsf. In a typical dynamic page, there is NOT a 1-to-1 mapping between a backing bean and a navigated page. A page is made of many dynamic fragments, each fragment has its own backing bean to receive data input from user and to push relevant data back to the user depending on user request context. Jsf provides this required infrastructure and fully configurable under managed beans. For example, if user asks any information related to company X in your portal directory, the portal supply requested information together with user existing authorized services under a complete layout of company X name brand (with company X logo vision, product vision, and copyright, etc) by just changing the contents of the company backing bean. The components and layouts to make up a page are re-useable. Tiles enables you to encapsulate the layouts and insert dynamic fragments to the page. For example, your portal enables user with different portal tabs so user can organize his/her authorized services in relevant portal tab, named by the user in his/her own language. Each portal tab has differnet layout designed for its purpose. The design of your portlet authorized services may follow a typical portlet layout with a portlet header for current status of PortletMode and portlet WindowState, followed by portlet contents. Hence, in each portal tab page, you have a tab layout and the portlet layout as raw templates. You insert relevant contents to the raw components having their own backing beans in the raw templates. Tiles is a very clean and powerful for this job. Under Shale, Tiles can be a plug in, similar to current tiles under struts. The design can be similar to what has been done under MyFaces for tiles. Each nagigated page is routed to a tiles definition with its own layout. Any attribute in a definition can be a page fragment or another definition. This enables you to be simple at the beginning and further drill down for more dynamic content implementation. I hope someone has time to port Tiles under Shale so it can be used under any compliant JSF implementation. If i have time i will do it. But life will not always go according to your wishes. Currently, i use MyFaces + Tiles + Spring IoC. I will use Shale as a framework for application filter to leverage on whatever developed under Shale, while inserting whatever servlet filters you already have for your current applications using common-chain in Shale. BaTien DBGROUPS Please correct me if I am wrong. Thanks! Lee - 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]
Java.net exception when using ValidatorPlugIn
Hi List, I have a rather annoying problem with the ValidatorPlugIn in a project using Struts: 1) I implement the ValidatorPlugIn as stated in James Holmes Struts. The Complete Reference (and several other places). 2) In struts-config.xml I have !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.1//EN http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd; 3) In the validator-rules.xml file and validation.xml file I have this !DOCTYPE form-validation PUBLIC -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN http://jakarta.apache.org/commons/dtds/validator_1_1.dtd; The reference http://jakarta.apache.org/commons/dtds/validator_1_1.dtd; is mapped to the validator_1_1.dtd in the application directory. 3) Running the application in Oracle OC4J at one site behind a usual Linux PC firewall works. 4) Remove the internet connection and rerun the application. Result: it fails when it loads validator.xml with a java.net.Exception: http.//jakarta.apache.org could not be contacted. Remove the ValidatorPlugin from theapplication and the rerun. Result the application does not fail. 4) Run the application from Tomcat 5.0 behind a rather restrictive firewall with ValidatorPlugIn enabled. Result: The application fails with a timeout exception from java.net because http://jakarta.apache.org could not be contacted. 5) Run the application from Tomcat 5.0 behind a rather restrictive firewall without ValidatorPlugIn enabled. Result: The applicaiton does not fail. 6) Put in a hard reference like this and rerun the application behind the firewall !DOCTYPE form-validation PUBLIC -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN /usr/local/Struts/dtds/commons/dtds/validator_1_1.dtd Result: The application runs. Conclusion: The mapping in 2) does not require the xml parser to validate the document against http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd but the ValidatorPlugIn forces the xml parser to validate the document against http://jakarta.apache.org/commons/dtds/validator_1_1.dtd So my question is simple: How do I configure the application server so it does not validate against the real dtd? Why is ValidatorPlugIn a special case in this context? Regards Flemming G. Jensen -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java.net exception when using ValidatorPlugIn
I have a rather annoying problem with the ValidatorPlugIn in a project using Struts: Can you look at this message (and its thread) and see if you are having the same problem? http://article.gmane.org/gmane.comp.jakarta.struts.user/96302 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: contrib/struts-shale-mailreader
Hi, is there any way to find out which versions of the commons-libs are included in a particular version of Struts. I'm especially interested in versions Struts 1.1 and 1.2.4? Thank you in advance for any hints. Regards Franz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Versions of commons-libs in Struts versions
Hi, is there any way to find out which versions of the commons-libs are included in a particular version of Struts. I'm especially interested in versions Struts 1.1 and 1.2.4? Thank you in advance for any hints. Regards Franz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nightly Builds
I've adjusted the nightly build scripts to account for the reorganization of our Subversion repository that was recently done, and caused last night's build (20041114) to break. Tonight's should be fine. Nightly builds of the core Struts distribution are at: Struts Core Distribution: Binaries: http://cvs.apache.org/builds/jakarta-struts/ Source: http://cvs.apache.org/builds/jakarta-struts/src/ In addition, I've started building two of the sandbox packages on a nightly basis to make progress on their development more accessible. The distributions for these packages are combined sources and binaries, so you only need one download. Struts-Chain: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/ Struts-Shale: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/ In addition, nightly builds of the Struts-Faces integration library (also combined binary and source) continue to be available: Struts-Faces: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versions of commons-libs in Struts versions
The easiest way to find out is to drop the struts-documentation.war into your servlet container for each of the versions and then look at the Installation section of the user guide (in the prerequisite software section). The struts web site has the latest version, but dependancies have changed since 1.2.4 (commons lang and collections have been removed as dependencies and beanutils and digester dependencies have moved on to the latest versions). http://struts.apache.org/userGuide/installation.html Niall - Original Message - From: Franz-Josef Herpers [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Sunday, November 14, 2004 9:23 PM Subject: Versions of commons-libs in Struts versions Hi, is there any way to find out which versions of the commons-libs are included in a particular version of Struts. I'm especially interested in versions Struts 1.1 and 1.2.4? Thank you in advance for any hints. Regards Franz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using multiple action forms in one action. Best practice?
Martin Kindler wrote: in my application I have a rather complex object to deal with. I have split the process in several jsps (JSP1, ..., JSPn) using different ActionForms (AF1, ..., AFm)... 2. merge all ActionForms to one big mega ActionForm Pro: works Con: no modularization; if I need to use one (partial) ActionForm in another place, I have to take everything or replicate the needed part You are talking about a wizard, right? IE, one logical form split over several JSP pages. In that case, I think you should just use one ActionForm with the data from all the JSP pages. I think the manual says something to the same effect. You can either: 1. make the ActionForm a session level form (see http://www.ajug.org/archive/ajug-members/10203/msg00066.html) 2. (or) make the ActionForm request level, in which case all your JSP pages must have hiden fields representing the data that has already been input on the previous JSP pages. I'm not sure how to do the forwarding from one JSP page to the next page (preserving the contents of the partially filled ActionForm). Do you need to write a dummy Action for each JSP page, or can you/should you forward directly from one JSP page to the next one, like this? Try it out and let me know, if you can. action path=/wizardPage1 name=wizardForm forward=/wizardPage2.jsp /action action path=/wizardPage2 name=wizardForm forward=/wizardPage3.jsp /action Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jericho and StrutsServerFaces
Would anyone be interested in working on a StrutsServerFaces consistent with the controller model in Jericho as opposed to the page based controller in JavaServerFaces? I am becoming more and more distanced from the idea of a page based controller, but do see that someone has to step up to the plate and provide at least one implementation of a decent view architecture for Struts. From what I can tell, Jericho is an extension and improvement on Struts and Shale simply is not Struts at all. JSF, however, does provide a lot of view code that could be massaged into interfaces consistent with Jericho but without the page based controller. If I am wrong, I would be happy to be corrected. I've gotten used to that in life. ;-) Looks like you were the original Jericho idea-guy, Ted. Are you working on that? Would you like a *sou chef* or do you already have a crew in house? Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: contrib/struts-shale-mailreader
Thanks for the great explaination, Batien! It certainly makes sense to have tiles to work with any JSF implementation! Lee On Sun, 14 Nov 2004 10:37:27 -0700, BaTien Duong [EMAIL PROTECTED] wrote: Struts User wrote: Having said all this, the framework is powerful for sophisticated web production side, where all fragments of each page are completely dynamic based on built-in backend intelligence. Tiles is appropriate for such page, rather than each page need a backing bean. Hi Batien, I am running the struts-shale-mailreader and just started to look into Java Server Faces and Shale. Thus, I am not totally familiar with the new frameworks and hope you can bear with me. Are you saying that Tile and backing bean don't have to co-exist? I thought Tiles and backing bean are two different things. Backing bean is sort of like ActionForm in Struts. More accurately, backing bean is like OzPage in Tak's introductory document. Backing beans and tiles need to co-exist in any decent dynamic web or portlet application. This is a very powerful presentation framework. Backing bean is a power tool under jsf. In a typical dynamic page, there is NOT a 1-to-1 mapping between a backing bean and a navigated page. A page is made of many dynamic fragments, each fragment has its own backing bean to receive data input from user and to push relevant data back to the user depending on user request context. Jsf provides this required infrastructure and fully configurable under managed beans. For example, if user asks any information related to company X in your portal directory, the portal supply requested information together with user existing authorized services under a complete layout of company X name brand (with company X logo vision, product vision, and copyright, etc) by just changing the contents of the company backing bean. The components and layouts to make up a page are re-useable. Tiles enables you to encapsulate the layouts and insert dynamic fragments to the page. For example, your portal enables user with different portal tabs so user can organize his/her authorized services in relevant portal tab, named by the user in his/her own language. Each portal tab has differnet layout designed for its purpose. The design of your portlet authorized services may follow a typical portlet layout with a portlet header for current status of PortletMode and portlet WindowState, followed by portlet contents. Hence, in each portal tab page, you have a tab layout and the portlet layout as raw templates. You insert relevant contents to the raw components having their own backing beans in the raw templates. Tiles is a very clean and powerful for this job. Under Shale, Tiles can be a plug in, similar to current tiles under struts. The design can be similar to what has been done under MyFaces for tiles. Each nagigated page is routed to a tiles definition with its own layout. Any attribute in a definition can be a page fragment or another definition. This enables you to be simple at the beginning and further drill down for more dynamic content implementation. I hope someone has time to port Tiles under Shale so it can be used under any compliant JSF implementation. If i have time i will do it. But life will not always go according to your wishes. Currently, i use MyFaces + Tiles + Spring IoC. I will use Shale as a framework for application filter to leverage on whatever developed under Shale, while inserting whatever servlet filters you already have for your current applications using common-chain in Shale. BaTien DBGROUPS Please correct me if I am wrong. Thanks! Lee - 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]
