Re: struts-dialogs on maven repo
I've allready made maven upload requests and build upload bundles. I've created upload bundles for struts-dialogs artifact and set JIRA issues : http://jira.codehaus.org/browse/MAVENUPLOAD-599 http://jira.codehaus.org/browse/MAVENUPLOAD-600 You may add comment to this issue if bundles seems invalid to you. Nico. Michael Jouravlev a écrit : On 11/21/05, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/21/05, Michael Jouravlev [EMAIL PROTECTED] wrote: Is struts-dialog extension available somewhere on maven repository ? As far as I know, it does not. Would you like it to be? You don't have to build it with Maven to get it into the repository, it's just a matter of getting files into the right directory structures so that people using Maven in their own projects can retrieve the artifacts. Here's how to request that releases be uploaded to the central Maven repository: http://maven.apache.org/guides/mini/guide-ibiblio-upload.html Another way is to set up the directory structure under the sourceforge website, similar to how the Maven Plugins sf project is doing it: http://maven-plugins.sourceforge.net/repository/maven-plugins/ I can help this weekend, if you want. -- Wendy Wendy, thank you for clearly laying out my options. I will think which approach is better for me and then try it later this week. Nicolas, I will make sure that Struts Dialogs is in Maven repo. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem: bean:define...
Hi!
I have a problem with defining an scripting variable with:
/bean:define id=Cmax name=adminFormBean property=Cmax
type=java.lang.Integer/
/and this property is defined into the bean called adminFormBean like this:
/private int Cmax = 0 ;
public void setCmax(int cmax) {
this.Cmax = cmax;
}
public int getCmax() {
return Cmax;
}
/But I get one JspException: /No getter method for property Cmax of
bean adminFormBean
/Can anyone help me, please? Thanks!!!
Eider
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem: bean:define...
Try to put lowercase
private int Cmax = 0 ; --- private int cmax = 0 ;
-Mensaje original-
De: Eider Iturbe [mailto:[EMAIL PROTECTED]
Enviado el: martes, 22 de noviembre de 2005 10:33
Para: Struts Users Mailing List
Asunto: Problem: bean:define...
Hi!
I have a problem with defining an scripting variable with:
/bean:define id=Cmax name=adminFormBean property=Cmax
type=java.lang.Integer/
/and this property is defined into the bean called adminFormBean like
this:
/private int Cmax = 0 ;
public void setCmax(int cmax) {
this.Cmax = cmax;
}
public int getCmax() {
return Cmax;
}
/But I get one JspException: /No getter method for property Cmax of
bean adminFormBean
/Can anyone help me, please? Thanks!!!
Eider
-
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: Problem: bean:define...
Hi Eider
Try
/bean:define id=cmax name=adminFormBean property=Cmax
type=java.lang.Integer/
the property=Cmax should be property=cmax. Struts is case
sensitive. If the method in the bean is setCmax then the property should
be accessed as cmax in any of the struts tag.
Have a Good Day!!!
Best Regards
Pal
-Original Message-
From: Eider Iturbe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 22, 2005 3:03 PM
To: Struts Users Mailing List
Subject: Problem: bean:define...
Hi!
I have a problem with defining an scripting variable with:
/bean:define id=Cmax name=adminFormBean property=Cmax
type=java.lang.Integer/
/and this property is defined into the bean called adminFormBean like
this:
/private int Cmax = 0 ;
public void setCmax(int cmax) {
this.Cmax = cmax;
}
public int getCmax() {
return Cmax;
}
/But I get one JspException: /No getter method for property Cmax of
bean adminFormBean
/Can anyone help me, please? Thanks!!!
Eider
-
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: Problem: bean:define...
Thanks to all! Writing the first letter in lowercase, it works well :-) !!
Eider
Ramaswamy, Palaniappan wrote:
Hi Eider
Try
/bean:define id=cmax name=adminFormBean property=Cmax
type=java.lang.Integer/
the property=Cmax should be property=cmax. Struts is case
sensitive. If the method in the bean is setCmax then the property should
be accessed as cmax in any of the struts tag.
Have a Good Day!!!
Best Regards
Pal
-Original Message-
From: Eider Iturbe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 22, 2005 3:03 PM
To: Struts Users Mailing List
Subject: Problem: bean:define...
Hi!
I have a problem with defining an scripting variable with:
/bean:define id=Cmax name=adminFormBean property=Cmax
type=java.lang.Integer/
/and this property is defined into the bean called adminFormBean like
this:
/private int Cmax = 0 ;
public void setCmax(int cmax) {
this.Cmax = cmax;
}
public int getCmax() {
return Cmax;
}
/But I get one JspException: /No getter method for property Cmax of
bean adminFormBean
/Can anyone help me, please? Thanks!!!
Eider
-
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: nested Sets
hi again, I guess it all comes down to how to make my POJO B (which contains the formulaPart-property) available in the scope. How would I do this? Is using Dynaforms the only solution? Or should I go with something like formdef (as described in http://www.mail-archive.com/user@struts.apache.org/msg32014.html)? from my struts-config.xml: form-bean name=myForm type=com.acme.struts.MyForm / action path=/myAction type=com.acme.struts.MyAction name=myForm scope=session parameter=method forward name=forward path=/protected/pages/crudOutage.jsp / /action cheers, pj -Opprinnelig melding- Fra: Danny Lee [mailto:[EMAIL PROTECTED] Sendt: 21. november 2005 17:18 Til: user@struts.apache.org Emne: Re: nested Sets Well, your problem is storing the value in formulaPart. What is formulaPart? You are populating the form, and you have lot of input fields after populations. So you have to have formulaPart[x] as a property, and List formulaPart in the scope! Read this: http://www.developer.com/java/ent/article.php/2233591 Cheers Danny Bouvet Konsulent schrieb: html:form action=myAction logic:iterate id=B name=myForm property=Bs html:text name=B property=formulaPart/ html:submit bean:message key=button.save/ /html:submit /logic:iterate /html:form when submitting the form, the value in B (formulaPart) is not updated. Any ideas what I'm doing wrong? Thanks for your help! cheers, pj - 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: nested Sets
The typical case for DynaForm is a very simple case, when you have couple of basic properties you have in your Form. I supose, that creating of a separate ActionForm class is more appropriate for your case. If you are new to Struts and have to work really fast (it was my case couple of months ago), maybe you have to use MyEclipse IDE. With myEclipse you can generate Hibernate mappings, DAO's and Struts stuff extremely fast. Especially Hibernating is fun with myEclipse, you create some table in mySql (or any other DB), and generating all the stuff for it in minutes, so in 5 minutes after creating a MySQL Table you can persist the data! :) Cheers Danny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
access rights for JAR
Can i specify in my Config Files(web.xml or struts-config.xml) that a JAR file cannot be downloaded without logging into the system?? Regards, Deepa
RE: [shale] Design questions
Is it possible to develop Shale application using Java Studio Creator? Oma. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bean:define and its behaviour....
Thanks to both of you
I've seen the servlet's code and indeed, Michael,
you're right...
I know deeper the bean:define mechanism
now...Thanks!
Cordialement,
- Original Message -
From:
Michael Jouravlev
To: Struts Users Mailing List
Sent: Monday, November 21, 2005 8:07
PM
Subject: Re: bean:define and its
behaviour
Gaet,This is not a Struts thing, this is a JSP thing.
read bean:definedocumentation [1] and look at the source code
generated by servletcontainer as James suggested. Documentation states
clearly in the veryfirst sentence that bean:define creates "a _new
attribute_ (in thescope specified by the toScope property, if any), and a
corresponding_scripting variable_". Source code, generated by Jasper,
shows thatscripting variable is created and initialized with value of JSP
scopedattribute. Then you change the value of scripting variable in
yourscriptlet, which is not reflected in any way back in JSP
scopedattribute.Try to change
bean:definetag to jsp:useBeanto
see a somewhat cleaner code generated by Jasper.Now the posible
solution: if you change this
% myVar = "content"; %to
this %
pageContext.setAttribute("myVar", "content"); %you example will work.
The above means to use scoped varable insteadof scriptlet variable. Try to
not mix scripting variables with scopedvariables. It is easier with JSTL,
which has cleaner syntax andautomatically looks up scoped variable in all
scopes. With JSTL theneed for scripting variables is greatly
reduced.[1] http://struts.apache.org/struts-taglib/tagreference-struts-bean.html#bean:defineMichael.On
11/21/05, James Harig [EMAIL PROTECTED]
wrote: Hi Gaet, If you are interested in knowing what
is going on, you can look at the java servlet that is generated from your
.jsp. For Tomcat, the servlets are in the CATALINA_BASE/work
directory. -Original Message- From:
Gaet [mailto:[EMAIL PROTECTED] Sent: Monday, November 21, 2005 12:46
PM To: Struts Users Mailing List Subject: Re:
bean:define and its behaviour Thanks for
reply Michael, I mean that it's certainly trivial for
experimented users with strutsnot like me :o) I try to look...but
I can't find the solutionwhy this variables are
different... Cordialement, -
Original Message - From: Michael mailto:[EMAIL PROTECTED]
Jouravlev To: Struts Users Mailing List mailto:user@struts.apache.org
Sent: Monday, November 21, 2005 5:54 PM Subject: Re:
bean:define and its behaviour If it is trivial,
why won't you look it up yourself? The key is to understand that myVar
objects used here bean:define id="myVar"
value=""/ and here % myVar =
"content"; % are different.
Michael. On 11/21/05, Gaet [EMAIL PROTECTED] wrote:
Nobody knows the answer to this trivial question?
Thanks- Original
Message - From: Gaet To:
Mailing List Struts Sent: Monday, November 21, 2005
10:08 AM Subject: bean:define and its
behaviourHi,
I'm sure this question is easy to answer for
much of yours but I cannot figure out the following
behaviour :
bean:define id="myVar" value=""/
% myVar =
"content"; %
logic:notEmpty name="myVar"
% System.out.println("myVar is NOT EMPTY"); %
/logic:notEmpty
logic:empty name="myVar"
% System.out.println("myVar is EMPTY"); %
/logic:empty The following
snippet writes "myVar is EMPTY" on standard output, why?
What I have to write to have "myVar is NOT EMPTY"?
Thanks very much for your help
-
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]
MappingDispatchAction executing twice
Hi,
I am using Struts 1.2.7. The DispatchAction and its variants
MappingDispatchAction and ActionDispatcher
seems to be executing twice for me. Not sure where is the problem.
Here is the code snippet. I tried with extending MappingDispatchAction or
using
ActionDispatcher
CommonAction extends MappingDispatchAction {
}
Page1Action extends CommonAction {
public ActionForward create(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
}
public ActionForward save(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
}
}
The struts config is
action path=/create type=com.company.app.action.Page1Action
name=createActionForm parameter=create scope=request
validate=false input=/create.jsp
/action
Any help is appreciated. I need to have CommonAction class which saves me
for lots of
convenient method coding
Best Regards
sumo
MappingDispatchAction executing twice
Hi,
I am using Struts 1.2.7. The DispatchAction and its variants
MappingDispatchAction and ActionDispatcher
seems to be executing twice for me. Not sure where is the problem.
Here is the code snippet. I tried with extending MappingDispatchAction or
using
ActionDispatcher
CommonAction extends MappingDispatchAction {
}
Page1Action extends CommonAction {
public ActionForward create(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
}
public ActionForward save(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
}
}
The struts config is
action path=/create type=com.company.app.action.Page1Action
name=createActionForm parameter=create scope=request
validate=false input=/create.jsp
/action
Any help is appreciated. I need to have CommonAction class which saves me
for lots of
convenient method coding
Best Regards
sumo
Re: bean:define and its behaviour....
Hi Michael, Sorry to disturb again, just another question : If i use scoped variable, than what do I must write in value attribute of a notEqual tag? So what do I have to write instead of nested:notEqual property=idservice value=%=myVar% I have tried nested:notEqual property=idservice value=(String)pageContext.getAttribute(myVar) But I got a nullPointerExceptionwhat is the right code? Or in this case, may it is prefer to use scripting variables? Thanks for help! Gaet' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] Design questions
Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Craig McClanahan Sent: Tuesday, November 22, 2005 6:15 AM To: Struts Users Mailing List Subject: Re: [shale] Design questions On 11/21/05, Alexandre Poitras [EMAIL PROTECTED] wrote: Hi! First of all, congratz on the good job. Shale looks very promising. We are currently implementing JSF in my organization. I already knew about Shale but I hadn't checked its progress in a while and I must say I am impressed so far. Actually, I stumbled upon the project while I was looking for a way to build in a quick way new UI components. The idea of creating 3 different classes each time to be able to aggregate some already existing UI components didn't sound particulary attractive. And that's how I found the goodies of Shale. Welcome! Anyway, to make it short, I am experimenting Clay's feature right now but I am a little bit confused. There seems to be a bit of overlap between Tiles and Clay features? Am I correct? And if it's true, is it a better choice to keep using Tiles as my layout manager or should I do it the Tapestry's way and treat everything as a UI component with the help of Clay? Clay is ... um, err ... pretty malleable :-). And yes, from the point of view of layout templating, there is definitely overlap. Tiles support has been a highly requested capability for JSF based applications, primarily because existing Struts developers are comfortable with it, and being able to reuse that capability meant a little bit less of an initial learning curve was necessary. My personal feeling is that Clay (or a similar project at java.net http://java.net called facelets) will become more popular for people coming to JSF without a large Struts legacy. The approach is more flexible and fine grained, and it wouldn't surprise me if we can make it perform better as well since it omits the need to use the container's RequestDispatcher.include() functionality. Another thought that keeps rambling through my head is a question concerning the backing beans design. I have red on many blogs entries that one of the greatest strength of JSF is the fact that the backing beans don't have to implements any interfaces. But if you want to take advantage of Shake page level services infrastructure (the view package), your beans have to implement the ViewController interface. Don't get me wrong, I think those services are great tools but I was wondering if all the beans should be ViewController instances or just when it is absolutly necessary? My personal habit is to use the interfaces all the time ... then I can focus my attention on the event driven parts of the design, and never run into situations where I define an init() method later, but it never gets called ... because I forgot to add implements ViewController up at the top of the class. Even better, if you're going to commit to doing this anyway, is to extends AbstractViewController instead of implements ViewController. Not only does this give you a bit of protection if ViewController ever changes, it also gives you a bunch of other nice convenience methods that makes things like the programmatic evaluation of value binding expressions much easier. One of the reasons people tout the no required interfaces possibility in JSF as an advantage is that it makes backing beans much easier to build unit tests for. However, Shale's approach is to protect this testability advantage, while still giving you the usability advantages of the extra events. It even includes a test framework to help you build unit tests for your view controllers very easily. Finally, another concern I have with this approach is that it's kind of suggesting you to write one bean for each page of the application (using a 1:1 mapping). From all the research I have done in the JSF area, I have not been able to find a consensus about wich approach to use when designing backing bean. Actually, it's hard to find some documentation on backing beans design but I think it's one of the challenges Struts developpers (as I am) face when moving to JSF. I would like to hear from the Shale users or/and developpers their opinion on the subject? Any advantage or downside? Ironically, my preferred design for backing beans is going to be something more familiar to WebWorks users than it is to Struts users, because it's closer to the way WebWorks already works :-). In Struts terms, think of the backing bean as a combination of an ActionForm and an Action, but with some additional flexibility: * Like an ActionForm, the bean would have a getter and setter for each form field. Unlike an ActionForm, the property types can be the appropriate native type (int, Date, or whatever you need) because JSF handles type conversions instead of making you do it. You would typically use a value binding expression
javascript in validator
One of the requirement in my application is that I should not use the client side javascript as the browsers the user use might not have the javascript enabled in their browsers. In my jsp there are 2 radio buttons. one of which is enable by default. When the user clicks on either of those he/she should be promted with some message depending on which radio button they pressed Yes/No. Using DynaValidatorForm. Can I do this in struts validator xml? if so how to do this? Thanks. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Design questions
Thank for the advices Craig . I'll do some pratical experiments with Shale now. By the wat, I have found an interesting post on Sun Java forums about backing beans design. Here's the link in case some other users are interested in the subject : http://forum.java.sun.com/thread.jspa?threadID=667941messageID=3907524 On 11/22/05, Nwokoma, Sampson [EMAIL PROTECTED] wrote: Is it possible to develop Shale application using Java Studio Creator? Oma. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandre Poitras Québec, Canada
RE: [shale] Design questions
Is it strictly a coincidence that the use of a 'backing bean' sound quite a bit like ATG Dynamo's 'FormHandler'? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, November 22, 2005 12:15 AM To: Struts Users Mailing List Subject: Re: [shale] Design questions On 11/21/05, Alexandre Poitras [EMAIL PROTECTED] wrote: Hi! First of all, congratz on the good job. Shale looks very promising. We are currently implementing JSF in my organization. I already knew about Shale but I hadn't checked its progress in a while and I must say I am impressed so far. Actually, I stumbled upon the project while I was looking for a way to build in a quick way new UI components. The idea of creating 3 different classes each time to be able to aggregate some already existing UI components didn't sound particulary attractive. And that's how I found the goodies of Shale. Welcome! Anyway, to make it short, I am experimenting Clay's feature right now but I am a little bit confused. There seems to be a bit of overlap between Tiles and Clay features? Am I correct? And if it's true, is it a better choice to keep using Tiles as my layout manager or should I do it the Tapestry's way and treat everything as a UI component with the help of Clay? Clay is ... um, err ... pretty malleable :-). And yes, from the point of view of layout templating, there is definitely overlap. Tiles support has been a highly requested capability for JSF based applications, primarily because existing Struts developers are comfortable with it, and being able to reuse that capability meant a little bit less of an initial learning curve was necessary. My personal feeling is that Clay (or a similar project at java.net http://java.net called facelets) will become more popular for people coming to JSF without a large Struts legacy. The approach is more flexible and fine grained, and it wouldn't surprise me if we can make it perform better as well since it omits the need to use the container's RequestDispatcher.include() functionality. Another thought that keeps rambling through my head is a question concerning the backing beans design. I have red on many blogs entries that one of the greatest strength of JSF is the fact that the backing beans don't have to implements any interfaces. But if you want to take advantage of Shake page level services infrastructure (the view package), your beans have to implement the ViewController interface. Don't get me wrong, I think those services are great tools but I was wondering if all the beans should be ViewController instances or just when it is absolutly necessary? My personal habit is to use the interfaces all the time ... then I can focus my attention on the event driven parts of the design, and never run into situations where I define an init() method later, but it never gets called ... because I forgot to add implements ViewController up at the top of the class. Even better, if you're going to commit to doing this anyway, is to extends AbstractViewController instead of implements ViewController. Not only does this give you a bit of protection if ViewController ever changes, it also gives you a bunch of other nice convenience methods that makes things like the programmatic evaluation of value binding expressions much easier. One of the reasons people tout the no required interfaces possibility in JSF as an advantage is that it makes backing beans much easier to build unit tests for. However, Shale's approach is to protect this testability advantage, while still giving you the usability advantages of the extra events. It even includes a test framework to help you build unit tests for your view controllers very easily. Finally, another concern I have with this approach is that it's kind of suggesting you to write one bean for each page of the application (using a 1:1 mapping). From all the research I have done in the JSF area, I have not been able to find a consensus about wich approach to use when designing backing bean. Actually, it's hard to find some documentation on backing beans design but I think it's one of the challenges Struts developpers (as I am) face when moving to JSF. I would like to hear from the Shale users or/and developpers their opinion on the subject? Any advantage or downside? Ironically, my preferred design for backing beans is going to be something more familiar to WebWorks users than it is to Struts users, because it's closer to the way WebWorks already works :-). In Struts terms, think of the backing bean as a combination of an ActionForm and an Action, but with some additional flexibility: * Like an ActionForm, the bean would have a getter and setter for each form field. Unlike an ActionForm, the property types can be the appropriate native type (int, Date, or whatever you need) because JSF handles type conversions instead of making you do it. You would typically use a value
[shale] Design questions
Is it possible to develop Shale using Java Studio Creator? Oma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Upgrade from struts1.0 to 1.2
Have you moved your Action code from the perform() method to the execute() method? - George http://www.idiacomputing.com/ -Original Message- From: bhas4 [mailto:[EMAIL PROTECTED] Sent: Thursday, November 10, 2005 9:20 AM To: user@struts.apache.org Subject: Re:Upgrade from struts1.0 to 1.2 Yes, I have tried everything that is relavent for the upgrade as mentioned in the wiki page - http://wiki.apache.org/struts/StrutsUpgradeNotes11to124, I do not see any wiki pages that talk about upgrade from 1.0 to 1.2 version, could only get 1.1 to 1.2 document. As per the above wiki page, I have done - 1. jars -- using the 1.2 jars required common jar files 2. tlds -- my tlds are defined in web.xml as per the document no change is required I would not be using new features of tld, so no changes done 3. validator.xml -- changed the dtd to point to 1.2 4. validator-rules.xml -- using the new version of .xml file 5. struts-config.xml -- changed the dtd to point to 1.2 verified that I'm not using any of the deprecated attributes 6. ActionError(s) ActionMessage(s) -- I have some usage of ActionError, but not changed yet --- NOT SURE if this will lead to the problem I'm facing. 7. Custom Tags Validation -- I have some usage of RequestUtils ResponseUtil, not changed yet -- but see these classes still exist in struts 1.2, IS THIS causing the issue for me? 8. init-param web.xml -- removed the attributes that are not supported any more added the required one application to my struts-config.xml under message-resources 9. html:form -- I have not used any of the tags that are deprecated 10. MessageResource bundle requirement -- I have not done this step, could this be leading to the issue?? -Bhaskar -- -- Broadband interface (RIA) + mail box saftey = a href=http://Struts_User_List.roomity.com;Struts_User_List.ro omity.com/a *Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131632395152~~ -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Design questions
Composition is a preferred design instead of inheritance. So, implementing composition, with inheritance does not make much sense. On 11/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Craig McClanahan Sent: Tuesday, November 22, 2005 6:15 AM To: Struts Users Mailing List Subject: Re: [shale] Design questions On 11/21/05, Alexandre Poitras [EMAIL PROTECTED] wrote: Hi! First of all, congratz on the good job. Shale looks very promising. We are currently implementing JSF in my organization. I already knew about Shale but I hadn't checked its progress in a while and I must say I am impressed so far. Actually, I stumbled upon the project while I was looking for a way to build in a quick way new UI components. The idea of creating 3 different classes each time to be able to aggregate some already existing UI components didn't sound particulary attractive. And that's how I found the goodies of Shale. Welcome! Anyway, to make it short, I am experimenting Clay's feature right now but I am a little bit confused. There seems to be a bit of overlap between Tiles and Clay features? Am I correct? And if it's true, is it a better choice to keep using Tiles as my layout manager or should I do it the Tapestry's way and treat everything as a UI component with the help of Clay? Clay is ... um, err ... pretty malleable :-). And yes, from the point of view of layout templating, there is definitely overlap. Tiles support has been a highly requested capability for JSF based applications, primarily because existing Struts developers are comfortable with it, and being able to reuse that capability meant a little bit less of an initial learning curve was necessary. My personal feeling is that Clay (or a similar project at java.net http://java.net http://java.net called facelets) will become more popular for people coming to JSF without a large Struts legacy. The approach is more flexible and fine grained, and it wouldn't surprise me if we can make it perform better as well since it omits the need to use the container's RequestDispatcher.include() functionality. Another thought that keeps rambling through my head is a question concerning the backing beans design. I have red on many blogs entries that one of the greatest strength of JSF is the fact that the backing beans don't have to implements any interfaces. But if you want to take advantage of Shake page level services infrastructure (the view package), your beans have to implement the ViewController interface. Don't get me wrong, I think those services are great tools but I was wondering if all the beans should be ViewController instances or just when it is absolutly necessary? My personal habit is to use the interfaces all the time ... then I can focus my attention on the event driven parts of the design, and never run into situations where I define an init() method later, but it never gets called ... because I forgot to add implements ViewController up at the top of the class. Even better, if you're going to commit to doing this anyway, is to extends AbstractViewController instead of implements ViewController. Not only does this give you a bit of protection if ViewController ever changes, it also gives you a bunch of other nice convenience methods that makes things like the programmatic evaluation of value binding expressions much easier. One of the reasons people tout the no required interfaces possibility in JSF as an advantage is that it makes backing beans much easier to build unit tests for. However, Shale's approach is to protect this testability advantage, while still giving you the usability advantages of the extra events. It even includes a test framework to help you build unit tests for your view controllers very easily. Finally, another concern I have with this approach is that it's kind of suggesting you to write one bean for each page of the application (using a 1:1 mapping). From all the research I have done in the JSF area, I have not been able to find a consensus about wich approach to use when designing backing bean. Actually, it's hard to find some documentation on backing beans design but I think it's one of the challenges Struts developpers (as I am) face when moving to JSF. I would like to hear from the Shale users or/and developpers their opinion on the subject? Any advantage or downside? Ironically, my preferred design for backing beans is going to be something more familiar to WebWorks users than it is to Struts users, because it's closer to the way WebWorks already works :-). In Struts terms, think of the backing bean as a combination of an ActionForm and an Action, but with some additional flexibility:
Re: [shale] Design questions
On 11/22/05, Nwokoma, Sampson [EMAIL PROTECTED] wrote: Is it possible to develop Shale using Java Studio Creator? Oma At this point, the application models supported by Shale and Creator 2 are similar but not identical. You'll find that Creator's page beans are very similar in functionality to Shale's ViewController, and the similarities are likely to increase in the future. Creator 2 won't give you any direct help in configuring things like Shale's dialogs, but they should be compatible. Craig
Re: access rights for JAR
I imagine that the same mechanism that protects a web directory would work. One example would be to specify in the web.xml for the container to protect a given directory with authentication. See any book on servlets or JSP about that one. There are more sophisticated ways, but given the general nature of your question, I would start with that general solution. - Nick On 11/22/05, Deepa Khetan [EMAIL PROTECTED] wrote: Can i specify in my Config Files(web.xml or struts-config.xml) that a JAR file cannot be downloaded without logging into the system?? Regards, Deepa
Re: How would you solve this problem?
We thought about that, but at first blush that seemed worse. The biggest problem is that each page is going to have N number of spans containing N number of data relating to the provider. So the popup getting called from page one may have to update... Provider Name Provider Address and the popup getting called from page two may have to update... Provider Name That's the real problem. As far as the form goes, the biggest problem is how to get the name of the form to be somehow passed into the JavaScript in a way that the same JavaScript can be used for multiple forms when all we want to do is change one value. Or maybe we should give in and use forms[0].X, etc. Preston [EMAIL PROTECTED] 11/19/2005 11:57:50 AM Preston CRAWFORD wrote: Yeah, no easy solution for this. The more I think about it the more it occurs to me that what we're attempting to do is setup a common code base for updating any N number of forms using Javascript. The plumbing for this is easy and obvious (I listed it earlier). But making it a single code base that can be applied to any form is going to be impossible. We're going to have to have a separate JSP for the popup for each form. I can't think of a way to make the pop that's being used in the form dynamic, without burying a great deal of logic in an Action. Or worse, actually submitting the form (but not submitting it to save), and then refreshing. So essentially having control logic in the action as to what kind of submission (as we leave the page and go to the provider search page) was just performed. I'm thinking this is going to end up being multiple actions, multiple JSP pages, multiple action entries in struts-config. That sounds horrendous, and I'm not sure why you'd need it. I might be missing something, but why can't you write one Javascript function that knows how to serialize a form into an object and pass it to a callback, and just include that function in each popup? 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]
RE: [shale] Design questions
Craig, Thank you a lot for your reply. I respect you a lot so it is with all due respect that I asking this: why crave out an entire new framework as shale when JSF should have been extended to take care of whatever shale represents. I am learning shale, and I am grudging about having to code the tags--something I do not have to do with Java Studio Creator for JSF. My thinking is that Creator should be extended to enable developers to choose whether to develop JSF specific or Shale specific application. What do you think? Oma. Oma Sampson DPSCS IT Systems Technical Specialist Email: [EMAIL PROTECTED] Pager: [EMAIL PROTECTED] Craig, Thank you a lot for your reply. Meanwhile, which IDE is around for developing visually the view layer of shale application? Instead of a new IDE, Studio Creator should be extended for Shale. I am just learning Shale cuz we use struts at work but hand coding everything takes the fun out of design experience compare to developing visually with Creator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] Design questions
Oma, If you are having trouble coding tags, which suggests you are using Shale's Clay feature, you might want to check out Facelets which has similar display properties to CLay. The URL is https://facelets.dev.java.net and I found it much easier to learn than what I've seen of Clay. Regards, David -Original Message- From: Nwokoma, Sampson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 12:16 PM To: Struts Users Mailing List Cc: mailto:craigmcc@gmail.com Subject: RE: [shale] Design questions Craig, Thank you a lot for your reply. I respect you a lot so it is with all due respect that I asking this: why crave out an entire new framework as shale when JSF should have been extended to take care of whatever shale represents. I am learning shale, and I am grudging about having to code the tags--something I do not have to do with Java Studio Creator for JSF. My thinking is that Creator should be extended to enable developers to choose whether to develop JSF specific or Shale specific application. What do you think? Oma. Oma Sampson DPSCS IT Systems Technical Specialist Email: [EMAIL PROTECTED] Pager: [EMAIL PROTECTED] Craig, Thank you a lot for your reply. Meanwhile, which IDE is around for developing visually the view layer of shale application? Instead of a new IDE, Studio Creator should be extended for Shale. I am just learning Shale cuz we use struts at work but hand coding everything takes the fun out of design experience compare to developing visually with Creator. - 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: [shale] Design questions
David, What is the difference between Java Studio Creator and Facelets since both are tools for developing JSF. Is Facelets for developing Shale? Oma -Original Message- From: David G. Friedman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 12:28 PM To: Struts Users Mailing List Subject: RE: [shale] Design questions Oma, If you are having trouble coding tags, which suggests you are using Shale's Clay feature, you might want to check out Facelets which has similar display properties to CLay. The URL is https://facelets.dev.java.net and I found it much easier to learn than what I've seen of Clay. Regards, David -Original Message- From: Nwokoma, Sampson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 12:16 PM To: Struts Users Mailing List Cc: mailto:craigmcc@gmail.com Subject: RE: [shale] Design questions Craig, Thank you a lot for your reply. I respect you a lot so it is with all due respect that I asking this: why crave out an entire new framework as shale when JSF should have been extended to take care of whatever shale represents. I am learning shale, and I am grudging about having to code the tags--something I do not have to do with Java Studio Creator for JSF. My thinking is that Creator should be extended to enable developers to choose whether to develop JSF specific or Shale specific application. What do you think? Oma. Oma Sampson DPSCS IT Systems Technical Specialist Email: [EMAIL PROTECTED] Pager: [EMAIL PROTECTED] Craig, Thank you a lot for your reply. Meanwhile, which IDE is around for developing visually the view layer of shale application? Instead of a new IDE, Studio Creator should be extended for Shale. I am just learning Shale cuz we use struts at work but hand coding everything takes the fun out of design experience compare to developing visually with Creator. - 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: [shale] Design questions
Facelets is a display technology similar to Shale's Clay component. Both are like tiles on steroids but tailored to be used with a JSF implementation (the Sun RI or the MyFaces runtime for example). I prefer Facelets over the Shale Clay features. Both are different from Java Studio Creator, which is an integrated development environment. Regards, David -Original Message- From: Nwokoma, Sampson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 12:35 PM To: Struts Users Mailing List Subject: RE: [shale] Design questions David, What is the difference between Java Studio Creator and Facelets since both are tools for developing JSF. Is Facelets for developing Shale? Oma -Original Message- From: David G. Friedman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 12:28 PM To: Struts Users Mailing List Subject: RE: [shale] Design questions Oma, If you are having trouble coding tags, which suggests you are using Shale's Clay feature, you might want to check out Facelets which has similar display properties to CLay. The URL is https://facelets.dev.java.net and I found it much easier to learn than what I've seen of Clay. Regards, David -Original Message- From: Nwokoma, Sampson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 12:16 PM To: Struts Users Mailing List Cc: mailto:craigmcc@gmail.com Subject: RE: [shale] Design questions Craig, Thank you a lot for your reply. I respect you a lot so it is with all due respect that I asking this: why crave out an entire new framework as shale when JSF should have been extended to take care of whatever shale represents. I am learning shale, and I am grudging about having to code the tags--something I do not have to do with Java Studio Creator for JSF. My thinking is that Creator should be extended to enable developers to choose whether to develop JSF specific or Shale specific application. What do you think? Oma. Oma Sampson DPSCS IT Systems Technical Specialist Email: [EMAIL PROTECTED] Pager: [EMAIL PROTECTED] Craig, Thank you a lot for your reply. Meanwhile, which IDE is around for developing visually the view layer of shale application? Instead of a new IDE, Studio Creator should be extended for Shale. I am just learning Shale cuz we use struts at work but hand coding everything takes the fun out of design experience compare to developing visually with Creator. - 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: [shale] Design questions
On 11/22/05, Nwokoma, Sampson [EMAIL PROTECTED] wrote: Craig, Thank you a lot for your reply. I respect you a lot so it is with all due respect that I asking this: why crave out an entire new framework as shale when JSF should have been extended to take care of whatever shale represents. For the long term, I absolutely agree with you ... and Shale will certainly serve as good research and development for what should be standardized in JSF 2.0. For JSF 1.0, we were already later than we should have been, so we stopped at the basic component APIs in order to get the thing out the door. If we'd waited until the spec was complete (in the sense of including all the application framework stuff), it *still* would not be done. I am learning shale, and I am grudging about having to code the tags--something I do not have to do with Java Studio Creator for JSF. My thinking is that Creator should be extended to enable developers to choose whether to develop JSF specific or Shale specific application. What do you think? Oma. Personally, I think that would be a great idea :-). However, I would suggest a slight terminology change, because every Shale app is also JSF specific. It would be more an issue of do you want to use the Shale value add features *in addition to* those of pure JSF. Oma Sampson DPSCS IT Systems Technical Specialist Email: [EMAIL PROTECTED] Pager: [EMAIL PROTECTED] Craig
RE: [shale] Design questions
Where can I get a good tutorial on Shale? Oma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Design questions
On Tue, November 22, 2005 1:24 pm, Craig McClanahan said: For the long term, I absolutely agree with you ... and Shale will certainly serve as good research and development for what should be standardized in JSF 2.0. Craig, that's an interesting comment, and I'd like to ask you to expand on it... specifically, are there plans to ensure forward-compatibility between Shale and JSF 2.0? The question I'm really getting at is if I start a Shale app today, ignoring whatever changes may come down in Shale itself since it's still a work-in-progress, will I be able to migrate my app to JSF 2.0, which it *sounds* like should wind up being comperable to Shale in terms of what it offers, or do I really need to make a choice between two divergent paths (even if the paths largely wind up intersecting)? In other words, is Shale future-proof with regard to JSF 2.0? :) Craig Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Design questions
On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, November 22, 2005 1:24 pm, Craig McClanahan said: For the long term, I absolutely agree with you ... and Shale will certainly serve as good research and development for what should be standardized in JSF 2.0. Craig, that's an interesting comment, and I'd like to ask you to expand on it... specifically, are there plans to ensure forward-compatibility between Shale and JSF 2.0? *Nobody* can make that kind of a promise ... the results of the JSF 2.0expert group deliberations will determine what actually happens in JSF 2.0. At the very least, the package names would change to javax.faces.something ... but it's likely to be a lot more than that -- standardization is a synthesis of approaches to individual technology areas, not an *annointing* of the particular approach taken by one individual package. A current analogy is what's going on with the Java Persistence API spec being developed as part of EJB3. The technology is fundamentally pretty similar to Hibernate, but it is *not* identical. Instead, Hibernate has plans to become an *implementation* of the new spec (along with potential other implementors such as TopLink). The question I'm really getting at is if I start a Shale app today, ignoring whatever changes may come down in Shale itself since it's still a work-in-progress, will I be able to migrate my app to JSF 2.0, which it *sounds* like should wind up being comperable to Shale in terms of what it offers, or do I really need to make a choice between two divergent paths (even if the paths largely wind up intersecting)? In other words, is Shale future-proof with regard to JSF 2.0? :) There's absolutely no way for me or anyone else to predict exactly what JSF 2.0 will look like. That being said, I'm personally committed to ensure that Shale evolves in a way that is compatible with the future of JSF. If JSF 2.0 offers a different approach to the same functional issue, Shale will continue to support its own, while also being compatible with the new standard way to do the same thing. In other words, if you start with Shale today you get to use cool stuff like ViewController and Dialogs now, instead of waiting months or years for JSF 2.0 to standardize them, and then some undefined longer amount of time for the JSF implementations to catch up. As a Struts project, once Shale gets to a General Availablility release (which *definitely* won't be true for at least the first few milestones), it will share the Struts community passion for backwards compatibility. However, even today, the documentation will include an indication of API stability for each individual package, so you can focus on the parts of Shale you plan to take advantage of. (This section seems to have gotten dropped from the javadocs, so I'm going to pull it out as a separate page in the website.) Craig Frank Craig
JSTL messages problem
Hello... I'm trying to display messages from a bundle using JSTL like so: fmt:message key=messages.appTitle / This isn't working, I'm getting: ???messages.appTitle??? However, doing: bean:message key=messages.appTitle/ Working fine. So I know the key is correct, and the bundle is being read, etc. I admit I haven't done much with JSTL, but this seems pretty simple. Do I need to do any other kind of setup to tell the JSTL tags about the bundle? Thanks! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Design questions
Thanks Craig, your comments will help in my deliberations at the moment, I appreciate you taking the time to reply :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 2:35 pm, Craig McClanahan said: On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, November 22, 2005 1:24 pm, Craig McClanahan said: For the long term, I absolutely agree with you ... and Shale will certainly serve as good research and development for what should be standardized in JSF 2.0. Craig, that's an interesting comment, and I'd like to ask you to expand on it... specifically, are there plans to ensure forward-compatibility between Shale and JSF 2.0? *Nobody* can make that kind of a promise ... the results of the JSF 2.0expert group deliberations will determine what actually happens in JSF 2.0. At the very least, the package names would change to javax.faces.something ... but it's likely to be a lot more than that -- standardization is a synthesis of approaches to individual technology areas, not an *annointing* of the particular approach taken by one individual package. A current analogy is what's going on with the Java Persistence API spec being developed as part of EJB3. The technology is fundamentally pretty similar to Hibernate, but it is *not* identical. Instead, Hibernate has plans to become an *implementation* of the new spec (along with potential other implementors such as TopLink). The question I'm really getting at is if I start a Shale app today, ignoring whatever changes may come down in Shale itself since it's still a work-in-progress, will I be able to migrate my app to JSF 2.0, which it *sounds* like should wind up being comperable to Shale in terms of what it offers, or do I really need to make a choice between two divergent paths (even if the paths largely wind up intersecting)? In other words, is Shale future-proof with regard to JSF 2.0? :) There's absolutely no way for me or anyone else to predict exactly what JSF 2.0 will look like. That being said, I'm personally committed to ensure that Shale evolves in a way that is compatible with the future of JSF. If JSF 2.0 offers a different approach to the same functional issue, Shale will continue to support its own, while also being compatible with the new standard way to do the same thing. In other words, if you start with Shale today you get to use cool stuff like ViewController and Dialogs now, instead of waiting months or years for JSF 2.0 to standardize them, and then some undefined longer amount of time for the JSF implementations to catch up. As a Struts project, once Shale gets to a General Availablility release (which *definitely* won't be true for at least the first few milestones), it will share the Struts community passion for backwards compatibility. However, even today, the documentation will include an indication of API stability for each individual package, so you can focus on the parts of Shale you plan to take advantage of. (This section seems to have gotten dropped from the javadocs, so I'm going to pull it out as a separate page in the website.) Craig Frank Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL messages problem
Place this in your web.xml file: context-param param-namejavax.servlet.jsp.jstl.fmt.localizationContext/param-name param-valuecom.omnytext.blah.blah.properties.ApplicationResources /param-value /context-param Where ApplicationResources.properties is the name of the message bundle in question. - Nick On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Hello... I'm trying to display messages from a bundle using JSTL like so: fmt:message key=messages.appTitle / This isn't working, I'm getting: ???messages.appTitle??? However, doing: bean:message key=messages.appTitle/ Working fine. So I know the key is correct, and the bundle is being read, etc. I admit I haven't done much with JSTL, but this seems pretty simple. Do I need to do any other kind of setup to tell the JSTL tags about the bundle? Thanks! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] Design questions
Personally, I think that would be a great idea :-). However, I would suggest a slight terminology change, because every Shale app is also JSF specific. It would be more an issue of do you want to use the Shale value add features *in addition to* those of pure JSF. Yes! Yes! You got it correct here! You certainly are in the position to make this suggestion to the Java Studio Creator team because there are a host of people --evidently I am one of them--who hate coding tags cuz we'd rather focus on the core business logic programming. That is why I am *married* to Java Studio Creator. However, given the popularity of Struts I cannot afford to ignore Shale. It will really be fantastic to develop application with Creator using Shale value add features. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL messages problem
Hi Nick, I added this but it still didn't work... One thing that didn't make sense to me is that I have app_resources_en.properties in WEB-INF/classes, so I wasn't sure how to qualify that in a package structure, so I just put param-valueapp_resources.properties/param-value... is that right or am I misunderstanding something? Thanks again! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 3:02 pm, Nick Sophinos said: Place this in your web.xml file: context-param param-namejavax.servlet.jsp.jstl.fmt.localizationContext/param-name param-valuecom.omnytext.blah.blah.properties.ApplicationResources /param-value /context-param Where ApplicationResources.properties is the name of the message bundle in question. - Nick On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Hello... I'm trying to display messages from a bundle using JSTL like so: fmt:message key=messages.appTitle / This isn't working, I'm getting: ???messages.appTitle??? However, doing: bean:message key=messages.appTitle/ Working fine. So I know the key is correct, and the bundle is being read, etc. I admit I haven't done much with JSTL, but this seems pretty simple. Do I need to do any other kind of setup to tell the JSTL tags about the bundle? Thanks! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [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: JSTL messages problem
Ah, I got it! The parameter should have been app_resources WITHOUT the .properties. Now it works. Thanks Nick, I appreciate your time! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 3:20 pm, Frank W. Zammetti said: Hi Nick, I added this but it still didn't work... One thing that didn't make sense to me is that I have app_resources_en.properties in WEB-INF/classes, so I wasn't sure how to qualify that in a package structure, so I just put param-valueapp_resources.properties/param-value... is that right or am I misunderstanding something? Thanks again! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 3:02 pm, Nick Sophinos said: Place this in your web.xml file: context-param param-namejavax.servlet.jsp.jstl.fmt.localizationContext/param-name param-valuecom.omnytext.blah.blah.properties.ApplicationResources /param-value /context-param Where ApplicationResources.properties is the name of the message bundle in question. - Nick On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Hello... I'm trying to display messages from a bundle using JSTL like so: fmt:message key=messages.appTitle / This isn't working, I'm getting: ???messages.appTitle??? However, doing: bean:message key=messages.appTitle/ Working fine. So I know the key is correct, and the bundle is being read, etc. I admit I haven't done much with JSTL, but this seems pretty simple. Do I need to do any other kind of setup to tell the JSTL tags about the bundle? Thanks! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [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: JSTL messages problem
Yep, just figured that out myself :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 3:27 pm, Wendy Smoak said: On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I added this but it still didn't work... One thing that didn't make sense to me is that I have app_resources_en.properties in WEB-INF/classes, so I wasn't sure how to qualify that in a package structure, so I just put param-valueapp_resources.properties/param-value... is that right or am I misunderstanding something? Thanks again! Leave off the '.properties' in the param-value. Other than that, yes. -- Wendy http://wiki.wsmoak.net/cgi-bin/wiki.pl?StrutsMessagesAndJSTL - 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: [shale] Design questions
On 11/22/05, Craig McClanahan [EMAIL PROTECTED] wrote: As a Struts project, once Shale gets to a General Availablility release (which *definitely* won't be true for at least the first few milestones), it will share the Struts community passion for backwards compatibility. However, even today, the documentation will include an indication of API stability for each individual package, so you can focus on the parts of Shale you plan to take advantage of. (This section seems to have gotten dropped from the javadocs, so I'm going to pull it out as a separate page in the website.) Just added the API stability page to the website: http://struts.apache.org/struts-shale/api-stability.html It also attempts to categorize the packages based on whether they are appropriate for *application* developers versus those that are trying to extend the *framework* itself. Craig
Re: JSTL messages problem
Ok, today is apparently the day I get to ask a bunch of stupid questions... Why doesn't this work? html:submit styleClass=cssButton value=fmt:message key=labels.loginButton / / I get... org.apache.jasper.JasperException: /index.jsp(36,83) equal symbol expected ...when I try it. bean:message doesn't work either... it's obviously a problem with embedding one taq in another, so I guess my quesion really is how does one label a submit button with a message from a bundle in general? I've done this in the past, but I've never tried it from within an html:submit, always a plain HTML input element, so it wasn't a nested custom tag. Thanks! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 3:27 pm, Wendy Smoak said: On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I added this but it still didn't work... One thing that didn't make sense to me is that I have app_resources_en.properties in WEB-INF/classes, so I wasn't sure how to qualify that in a package structure, so I just put param-valueapp_resources.properties/param-value... is that right or am I misunderstanding something? Thanks again! Leave off the '.properties' in the param-value. Other than that, yes. -- Wendy http://wiki.wsmoak.net/cgi-bin/wiki.pl?StrutsMessagesAndJSTL - 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: JSTL messages problem
On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ok, today is apparently the day I get to ask a bunch of stupid questions... Why doesn't this work? html:submit styleClass=cssButton value=fmt:message key=labels.loginButton / / You can't use a JSP tag as attribute of another JSP tag. Maybe try c:set with the fmt in the body, then use an expression for the value of html:submit? Which implies the use of the Struts-EL taglib, which you should be using if you're on Servlet 2.3/JSTL 1.0. If you haven't already, change the URI in %@ taglib and leave the prefix as 'html'. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale] Rolodex usecase
Hi, Here's one question for the developpers of Shale. Why the method createTabs() in the Rolodex ViewController embedds every bit of generated html markup inside a HtmlOutputText component. My guess is that it provides output escaping abilities for characters considered specials in HTML and maybe at the same time, it encapsulates (or could) the detection of some well-known Hackers Attacks (cross site scripting attack... reminds you of something...). So the question is basically what are the advantages and issues of using plain html markup vs using embedding the content inside HtmlOutputText components? Any other ideas? -- Alexandre Poitras Québec, Canada
Re: JSTL messages problem
I use this idiom all the time to get a message label on a button: html:submit property=button styleClass=longButton bean:message key=button.confirm/ /html:submit You should be able to substitute fmt:message above. -ed On 11/22/05, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ok, today is apparently the day I get to ask a bunch of stupid questions... Why doesn't this work? html:submit styleClass=cssButton value=fmt:message key=labels.loginButton / / You can't use a JSP tag as attribute of another JSP tag. Maybe try c:set with the fmt in the body, then use an expression for the value of html:submit? Which implies the use of the Struts-EL taglib, which you should be using if you're on Servlet 2.3/JSTL 1.0. If you haven't already, change the URI in %@ taglib and leave the prefix as 'html'. -- Wendy - 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: JSTL messages problem
On 11/22/05, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ok, today is apparently the day I get to ask a bunch of stupid questions... Why doesn't this work? html:submit styleClass=cssButton value=fmt:message key=labels.loginButton / / You can't use a JSP tag as attribute of another JSP tag. Maybe try c:set with the fmt in the body, then use an expression for the value of html:submit? snip/ fmt:message has a var/scope tuple for this purpose. -Rahul Which implies the use of the Struts-EL taglib, which you should be using if you're on Servlet 2.3/JSTL 1.0. If you haven't already, change the URI in %@ taglib and leave the prefix as 'html'. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL messages problem
On 11/22/05, Ed Griebel [EMAIL PROTECTED] wrote: I use this idiom all the time to get a message label on a button: html:submit property=button styleClass=longButton bean:message key=button.confirm/ /html:submit You should be able to substitute fmt:message above. What he said. :) I had to go look around the source code of an old project to refresh my memory and was about to post a similar example. Too much BASIC, not enough Java, lately... -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL messages problem
I admit I always forget the button and submit elements, among others, support body text. Had I remembered that I would have come up with this on my own :) But thanks Ed (and Wendy after the fact ;) ), that worked perfectly. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 4:21 pm, Ed Griebel said: I use this idiom all the time to get a message label on a button: html:submit property=button styleClass=longButton bean:message key=button.confirm/ /html:submit You should be able to substitute fmt:message above. -ed On 11/22/05, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ok, today is apparently the day I get to ask a bunch of stupid questions... Why doesn't this work? html:submit styleClass=cssButton value=fmt:message key=labels.loginButton / / You can't use a JSP tag as attribute of another JSP tag. Maybe try c:set with the fmt in the body, then use an expression for the value of html:submit? Which implies the use of the Struts-EL taglib, which you should be using if you're on Servlet 2.3/JSTL 1.0. If you haven't already, change the URI in %@ taglib and leave the prefix as 'html'. -- Wendy - 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: JSTL messages problem
On 11/22/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 11/22/05, Nick Sophinos [EMAIL PROTECTED] wrote: This is definitely not how JSTL recommends loading bundles (see fmt:bundle and fmt:setBundle). Ofcourse, its your decision. Can you explain more about this? I'm also using the context parameter, and I only have the one .properties file, the app has no need for i18n. It looks like fmt:setBundle would be done on each page, so I'm not sure what I'd gain from it. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using html:rewrite in Oracle Application Server 10g
I use Struts 1.2.7 and Oracle Application Server 10g 10.1.2. This is the first 5 lines in my login.jsp file: %@ taglib uri=/tags/struts-html prefix=html % html:html head titleBRAC Management Tool - Login/title link rel=stylesheet type=text/css href=html:rewrite page='/css/stylesheet.css' / / This file worked fine with Tomcat, but Oracle AS 10g said 500 Internal Server Error java.lang.NullPointerException at org.apache.struts.taglib.TagUtils.pageURL(TagUtils.java:1114) at org.apache.struts.taglib.TagUtils.computeURLWithCharEncoding(TagUtils.ja va:466) at org.apache.struts.taglib.html.RewriteTag.doStartTag(RewriteTag.java:57) at _login._jspService(_login.java:56) [SRC:/login.jsp:5] at com.orionserver[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].http.OrionHttpJspPage.service(OrionHttpJspPage.java:56) at oracle.jsp.runtimev2.JspPageTable.service(JspPageTable.java:347) at oracle.jsp.runtimev2.JspServlet.internalService(JspServlet.java:509) at oracle.jsp.runtimev2.JspServlet.service(JspServlet.java:413) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ServletRequestDispatcher.invoke(ServletRequest Dispatcher.java:810) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.ServletRequestDispatcher.forwardInternal(Servl etRequestDispatcher.java:322) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.HttpRequestHandler.processRequest(HttpRequestH andler.java:790) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:2 08) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:1 25) at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)].util.ReleasableResourcePooledExecutor$MyWorker.run(Releasa bleResourcePooledExecutor.java:192) at java.lang.Thread.run(Thread.java:534) Do you know the reason? All the examples going along with Struts (like struts-examples.war, struts-mailreader.war...) didn't use html:rewrite. They all can be deployed in Oracle AS 10g and run perfectly. Thanks for any help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
logic:equal looking for null
Hi , I have code like this. logic:equal name=viewPaymentsAndDisbursementsForm property=lastPaymentAmount value= 0.00 no payments have been applied to your account./span/td /logic:equal logic:greaterThan name=viewPaymentsAndDisbursementsForm property=lastPaymentAmount value=0.00 Some payments have been applied to your account./span/td /logic:greaterThan The Aboove code was working as long as lastPaymentAmount was double.But as per the requiremnt i had to change it to String.As per the new requirement i have to look for whether lastPaymentAmount is null or not.Which Struts Libs i need to use in this situation.. Thanks In Advance Srinivas
RE: logic:equal looking for null
Use logic:empty to test if it is null or an empty String. Use logic:notEmpty to test if it is not a null String and not an empty String Shawn -Original Message- From: Srinivas Jadcharla [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 3:55 PM To: Struts Users Mailing List Subject: logic:equal looking for null Hi , I have code like this. logic:equal name=viewPaymentsAndDisbursementsForm property=lastPaymentAmount value= 0.00 no payments have been applied to your account./span/td /logic:equal logic:greaterThan name=viewPaymentsAndDisbursementsForm property=lastPaymentAmount value=0.00 Some payments have been applied to your account./span/td /logic:greaterThan The Aboove code was working as long as lastPaymentAmount was double.But as per the requiremnt i had to change it to String.As per the new requirement i have to look for whether lastPaymentAmount is null or not.Which Struts Libs i need to use in this situation.. Thanks In Advance Srinivas This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tiles]
There are ways to put content into a tile but there isn't a way to remove a tile. Say we have a layout that has a menu by default then you extend that layout and you don't want a menu. I know struts-templates didn't work if you did a put on a blank value. Does this work with tiles? Why isn't there a remove or delete tag? Shawn This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network.
Re: [tiles]
On Nov 22, 2005, at 4:22 PM, Garner, Shawn wrote: I know struts-templates didn't work if you did a put on a blank value. Does this work with tiles? Hmm, I don't know. Try it and see what happens. I suspect it won't work. The only thing I can think of right now is to include a blank JSP but that's a terrible way to have to do it. Why isn't there a remove or delete tag? I've personally never thought of that. I'd be in favor of making an attribute optional, so that you can specify that it won't be displayed. We could accomplish it through the XML defs or through a JSP tag. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles]
On 11/22/05, Garner, Shawn [EMAIL PROTECTED] wrote: There are ways to put content into a tile but there isn't a way to remove a tile. Say we have a layout that has a menu by default then you extend that layout and you don't want a menu. I have that exact situation where I don't want the menu showing up on a resolution screen. I'm doing it in tiles-defs.xml, so this may not apply, but it works: tiles-definitions definition name=masterPage path=/WEB-INF/jsp/layout/basicLayout.jsp put name=title value=IRM Web / put name=menubar value=/WEB-INF/jsp/menubar.jsp / put name=footer value=/WEB-INF/jsp/footer.jsp / ... /definition definition name=resolution.page extends=masterPage put name=heading value=Resolution / put name=menubar value= / put name=bodyvalue=/WEB-INF/jsp/resolutionBody.jsp / /definition ... -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles]
On 11/22/05, Garner, Shawn [EMAIL PROTECTED] wrote: There are ways to put content into a tile but there isn't a way to remove a tile. Say we have a layout that has a menu by default then you extend that layout and you don't want a menu. Instead of thinking about removing tiles from a layout, I would suggest thinking about your hierarchy the other way around. Build a layout that does not have the menu, and another layout (extending the previous one) that does have a menu. Now, for any particular tile, choose the correct layout to extend based on whether you want the menu or not. Craig
Re: [tiles]
On Nov 22, 2005, at 4:42 PM, Wendy Smoak wrote: I have that exact situation where I don't want the menu showing up on a resolution screen. I'm doing it in tiles-defs.xml, so this may not apply, but it works: tiles-definitions definition name=masterPage path=/WEB-INF/jsp/layout/ basicLayout.jsp put name=title value=IRM Web / put name=menubar value=/WEB-INF/jsp/menubar.jsp / put name=footer value=/WEB-INF/jsp/footer.jsp / ... /definition definition name=resolution.page extends=masterPage put name=heading value=Resolution / put name=menubar value= / put name=bodyvalue=/WEB-INF/jsp/resolutionBody.jsp / /definition ... So it does work. How do you use the menubar definition in the JSP page? Are you using the insert tag? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How would you solve this problem?
On 11/22/05, Preston CRAWFORD [EMAIL PROTECTED] wrote: We thought about that, but at first blush that seemed worse. The biggest problem is that each page is going to have N number of spans containing N number of data relating to the provider. So the popup getting called from page one may have to update... Provider Name Provider Address and the popup getting called from page two may have to update... Provider Name That's the real problem. If you don't want to use parellel request (aka AJAX), why would not you just use a simple solution - reload the whole page (and have search form right in the main page)? Keep data in session, submit search and reload page with freshened up provider info. It would renew all relevant info automatically. Ok, so page flickers. Who cares? ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] Design questions
Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. I'm a big fan of Tiles and think that Clay and Tiles have their own niches. I see tiles as a tool for assembling page fragments in a reusable way. Clay is at a more granular level. It's focus is on assembling a page of reusable widgets. There are many ways to use Clay but I'll give the following example of inheritance and composition. component jsfid=baseInputText extends=inputText attributes !-- Convention mapping class attribute to styleClass property -- set name=styleClass value=@class/ /attributes symbols set name=class value=generic / /symbols /component component jsfid=panel extends=panelGrid element jsfid=baseInputText renderid=0 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=blue / /symbols /element element jsfid=baseInputText renderid=1 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=green / /symbols /element /component Elements form composition but also add inheritance similar to a java inner class. The new symbol replacement is sort of a tiles like feature where you can customize by overriding a symbol value. PS: I'm on vacation this week and have limited Internet access. Hermod Gary
Shale prerender() problem (sometimes!)
Hi all:
I have a situation where Page1 (/worklist.jsp) has a link which when
clicked is forwarded to Page2 (/worklist/nextAssignments.jsp). Since I
have to do some prerender work to display my Page2, I have code in my
backing Bean1's prerender() method. However, my breakpoint in Bean1's
prerender() is not being hit in this situation. (There are other cases
where it is being called just fine, .. but I just can't seem to see what's
wrong in this case.. and am wondering if I cannot maybe have the
worklist bean point to one bean and the worklist$nextAssignment point
to another..? Doesn't sound too logical but then I'm clutching at straws
at this point..(:()
Here's what I have in my faces-config.xml:
managed-bean
managed-bean-nameworklist/managed-bean-name
managed-bean-class
com.intellicare.webshark.action.workflow.WorkListManagerBean
/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
/managed-bean
navigation-rule
from-view-id*/from-view-id
navigation-case
from-outcomenextAssignment/from-outcome
to-view-id/worklist/nextAssignment.jsp/
to-view-id
/navigation-case
etc.
Also,
managed-bean
managed-bean-nameworklist$nextAssignment/
managed-bean-name
managed-bean-class
com.intellicare.webshark.action.workflow.WebworkManagerBean
/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
/managed-bean
The link on Page1 (/worklist.jsp) says:
h:form id=worklistForm
h:commandLink id=nextAssignment action=
#{worklist.acceptNextAssignment}
h:outputText value=Accept Next Assignment /
/h:commandLink
/h:form
When i click on the link above, my worklist bean's acceptNextAssignment()
method gets called fine and it finally returns the String nextAssignment
and thence forwards to /worklist/nextAssignment.jsp.
Can anyone spot what I am missing?
Many thanks in advance for your time,
Geeta
Re: [tiles]
On 11/22/05, Greg Reddin [EMAIL PROTECTED] wrote: So it does work. How do you use the menubar definition in the JSP page? Are you using the insert tag? I had to go look. Yes: tiles:insert attribute=menubar/ Don't take it as a recommendation-- all I'm going to say is it works. This is out of my very first Struts app which launched days after Struts 1.1 went final... no doubt I'd do things a little differently now. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tiles Again - Can anyone help?
I have had a problem niggling me for a couple of weeks. I keep going back to it and I'm sure there must be a simple solution, but I think I am missing something simple - struts overload, maybe? ;) I have MasterLayout.jsp and FormLayout.jsp. MasterLayout sets out a basic html page, specifying generic components like the title and menu using tiles:insert tags. FormLayout specifies a form, specifying components again using tiles:insert tags. I am defining tiles in tiles-def.xml that user MasterLayout - all working fine using the put tags to inject the components. But I also want tiles where in the tiles definition file I can use the put tags to add components into both the MasterLayout and the FormLayout. I hope this makes sense to someone. I can send more clarification if needed. Can anyone advise on this? -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: 22 November 2005 22:46 To: Struts Users Mailing List Subject: Re: [tiles] On Nov 22, 2005, at 4:42 PM, Wendy Smoak wrote: I have that exact situation where I don't want the menu showing up on a resolution screen. I'm doing it in tiles-defs.xml, so this may not apply, but it works: tiles-definitions definition name=masterPage path=/WEB-INF/jsp/layout/ basicLayout.jsp put name=title value=IRM Web / put name=menubar value=/WEB-INF/jsp/menubar.jsp / put name=footer value=/WEB-INF/jsp/footer.jsp / ... /definition definition name=resolution.page extends=masterPage put name=heading value=Resolution / put name=menubar value= / put name=bodyvalue=/WEB-INF/jsp/resolutionBody.jsp / /definition ... So it does work. How do you use the menubar definition in the JSP page? Are you using the insert tag? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3166 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL messages problem
Unfortunately I tried that... as Wendy said, the problem ultinately is really one tag nested within another. Frank Garner, Shawn wrote: It might also work to do this: html:submit styleClass=cssButton value=fmt:message key='labels.loginButton' / / Sometimes double quotes inside double quotes confuses the compiler. If you put single quotes inside the double quotes it might be able to better determine your meaning. Shawn -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 2:43 PM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: Re: JSTL messages problem Ok, today is apparently the day I get to ask a bunch of stupid questions... Why doesn't this work? html:submit styleClass=cssButton value=fmt:message key=labels.loginButton / / I get... org.apache.jasper.JasperException: /index.jsp(36,83) equal symbol expected ...when I try it. bean:message doesn't work either... it's obviously a problem with embedding one taq in another, so I guess my quesion really is how does one label a submit button with a message from a bundle in general? I've done this in the past, but I've never tried it from within an html:submit, always a plain HTML input element, so it wasn't a nested custom tag. Thanks! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How would you solve this problem?
Sorry for coming in late to the discussion but I only read this thread now.
I may have misunderstood the problem. I'm thinking the popup will
display a list of providers matching the search parameters, and the
user can select any of them by checking one, and the fields on the
form on the parent window displays the values for the checked
provider. And when the user selects another provider from the
results, the form updates itself on the parent window. Did I get it?
Well, if I'm close anyway, maybe what I'm thinking will work.
I would solve this problem by having the popup concentrate on
searching for a provider, and leave the problem of populating form
fields to the calling (parent) window.
The popup would have a reference to the parent, so I can call a JS
function on the parent. With JS, even the function to call can be
dynamic, so it could be a parameter that the parent window sends to
the popup (call my 'showProvider' method when the user selects a
provider). The parameter to the showProvider method would be the
provider ID.
When showProvider is called, it would send an XMLHttpRequest to
retrieve the details of said provider. I'd have a method which I can
call with the XML result of the call, as well as the form name or form
variable, and will begin to populate the fields that it finds. With a
decent naming convention, I can write this method so that I can reuse
it whereever I have this form.
The reusable portions would be the popup (completely parameterized),
the XMLHttpRequest handling, the form population function, even the
method that gets called when a provider is selected. The form names
would have to match across all the pages using it.
Hope this helps. Let me know if you want me to clarify any point.
Sorry if I misunderstood your problem and offered a bogus solution.
Hubert
On 11/17/05, Preston CRAWFORD [EMAIL PROTECTED] wrote:
Okay, this is a little complex, so hopefully I can describe it well so
as not to confuse anyone.
We have a need for the following. We need a reusable set of actions,
JSPs, etc. that operate in a popup to allow the user to search for a
medical provider. That's easy enough. The catch is this. The reason for
a popup is because the UI requirement is that the user perform the
search and then (as transparent as possible to them) have the page
refresh the portions of the display that say what medical provider is
currently selected. So you might have a page. In other words when the
search is performed a hidden form field will get updated (via Javascript
currently) with selected Provider ID. And then N number of fields are
going to be populated with some data to let the user know which provider
has been selected.
The trick is that since we're using Javascript currently the Javascript
is basically statically calling form names and form fields and changing
data based on what it's getting from the search action. So something
like this.
script type=text/javascript language=JavaScript
!--
function callOnloadFunctions() {
updateParentAndCloseSelf();
}
function updateParentAndCloseSelf() {
changeParentFormValue('medicalInfoForm', 'hospital', 'c:out
value=${chosenProvider} /');
changeParentDOMElement('hospitalLabel', 'c:out
value=${chosenProvider} /');
window.close();
}
//--
/script
Obviously problem #1 is that this JSP page can't be used on other views
because it references by name the name of the form. I'm not sure how to
dynamically get this to the JSP page without passing around a token of
some kind or passing around values in the request stream. That seems
like it could get ugly. Plus if I have to update, visually, more than
just the name of the hospital, for example, how would I handle that?
Imagining ANOTHER JSP page with separate Javascript.
function updateParentAndCloseSelf() {
changeParentFormValue('anotherForm', 'hospital', 'c:out
value=${chosenProvider} /');
changeParentDOMElement('hospitalLabel', 'c:out
value=${chosenProvider} /');
changeParentDOMElement('hospitalAddressLabel', 'c:out
value=${chosenProvider} /');
changeParentDOMElement('hospitalStateLabel', 'c:out
value=${chosenProvider} /');
window.close();
}
In short, it could get REALLY ugly.
Now another option is that we actually give in (I say give in because
it would mean a page refresh, something that might not go over well),
submit the form, but don't save the data to the database yet, and then
somehow via request or session retain any other field data they may have
changed for when we hit the page again, without saving it to the
database.
Okay, hopefully that makes some sense.
Basically we want a popup that performs a search, updates some data on
the page and in the form on the page, without actually doing the final
submit and save. And we'd like it to be reusable, if possible. So far we
can't think of the best way to approach this, in terms of
Re: Shale prerender() problem (sometimes!)
..never mind about my question. Just realised I was being really stupid. Sorry to waste your time, Geeta
shopping cart, dynamic field names
Sorry, I've search for hours but can't seem to find the answer to this basic problem. I'm building a shopping cart for the first time in struts. I have a display cart jsp that will show each item, and as expected, i have a qty textbox for each item and an update cart button. so each qty field will have to have, as part of its name, an id to tie it to the particular item in the cart. there is another field in each row, a remove checkbox, so i can't just name it the id. the cart hangs out in the session scope, and has a List of CartItem objects called items. the action, when called to show the cart, will call cart.getItems() and stick the List in the request, so that it can easily be referenced by the c:foreach tag that i will be using to create the html. So the only way i can figure to get those qty fields in the request to be set in the ActionForm, upon form submission, is to use a map in the ActionForm, since i won't know how many items there will be. So the ActionForm ends up with all of the qty fields in the map, with the key being the name attribute from the textbox, and the value being the quantity typed in by the user. So in the action upon form submission i can iterate through the keys, filter out all keys that start with qty and update the qty for those items. So this seems a little hackish, i was wondering if there's a better way, and secondly, what exactly do i have to name those textboxes to get struts to recognize that they are pointing to a Map. I'm guessing that it will be mapname.key, is that correct? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale prerender() problem (sometimes!)
On 11/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all: I have a situation where Page1 (/worklist.jsp) has a link which when clicked is forwarded to Page2 (/worklist/nextAssignments.jsp). Since I have to do some prerender work to display my Page2, I have code in my backing Bean1's prerender() method. If you are doing exactly what you describe above, you're doing it wrong. The only prerender() method that is called is for the view that will actually be rendered ... in other words, you should put the code in the prerender() method of Page2, not Page1. The whole idea is that all the code associated with a particular view should be in one class (the backing bean for that JSP page). Otherwise, if you had three different pages that all navigated to Page2, then you'd have to duplicate the setup logic in three different places. Craig
Re: JSTL messages problem
On 11/22/05, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/22/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 11/22/05, Nick Sophinos [EMAIL PROTECTED] wrote: This is definitely not how JSTL recommends loading bundles (see fmt:bundle and fmt:setBundle). Ofcourse, its your decision. Can you explain more about this? snip/ Ofcourse. I think Frank also asked a similar question, though the top posting in that email might have thrown me off. I'm also using the context parameter, and I only have the one .properties file, the app has no need for i18n. snap/ It boils down to what a technology *expects* the casual users to know. The param-name is merely an implementation detail (though the spec talks about it so its guaranteed to be the same name in all JSTL impls). Its similar to the casual user not needing to know that a Struts module is loaded under the attribute name Globals.MODULE_KEY + prefix. In addition, as you've noted, this approach mandates the app use a single basename bundle. It looks like fmt:setBundle would be done on each page, so I'm not sure what I'd gain from it. snip/ Why on every page? -Rahul Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale prerender() problem (sometimes!)
[EMAIL PROTECTED] wrote on 11/22/2005 06:13:01 PM: On 11/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all: I have a situation where Page1 (/worklist.jsp) has a link which when clicked is forwarded to Page2 (/worklist/nextAssignments.jsp). Since I have to do some prerender work to display my Page2, I have code in my backing Bean1's prerender() method. If you are doing exactly what you describe above, you're doing it wrong. The only prerender() method that is called is for the view that will actually be rendered ... in other words, you should put the code in the prerender() method of Page2, not Page1. Yes. Actually that's how I had it and then later decided to do some code cleanup and managed to foul it up instead! The horrid part is that I had been staring at it for the past hour - and I realised what i was doing wrong about three seconds after i hit the Send..(:( The whole idea is that all the code associated with a particular view should be in one class (the backing bean for that JSP page). Otherwise, if you had three different pages that all navigated to Page2, then you'd have to duplicate the setup logic in three different places. Craig Thank you and sorry again! Geeta
Re: JSTL messages problem
On 11/22/05, Garner, Shawn [EMAIL PROTECTED] wrote: It might also work to do this: html:submit styleClass=cssButton value=fmt:message key='labels.loginButton' / / Sometimes double quotes inside double quotes confuses the compiler. If you put single quotes inside the double quotes it might be able to better determine your meaning. snip/ I wouldn't recommend that. I suspect the only thing we might end up confusing is ourselves ;-) -Rahul Shawn -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 2:43 PM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: Re: JSTL messages problem Ok, today is apparently the day I get to ask a bunch of stupid questions... Why doesn't this work? html:submit styleClass=cssButton value=fmt:message key=labels.loginButton / / I get... org.apache.jasper.JasperException: /index.jsp(36,83) equal symbol expected ...when I try it. bean:message doesn't work either... it's obviously a problem with embedding one taq in another, so I guess my quesion really is how does one label a submit button with a message from a bundle in general? I've done this in the past, but I've never tried it from within an html:submit, always a plain HTML input element, so it wasn't a nested custom tag. Thanks! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, November 22, 2005 3:27 pm, Wendy Smoak said: On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I added this but it still didn't work... One thing that didn't make sense to me is that I have app_resources_en.properties in WEB-INF/classes, so I wasn't sure how to qualify that in a package structure, so I just put param-valueapp_resources.properties/param-value... is that right or am I misunderstanding something? Thanks again! Leave off the '.properties' in the param-value. Other than that, yes. -- Wendy http://wiki.wsmoak.net/cgi-bin/wiki.pl?StrutsMessagesAndJSTL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles Again - Can anyone help?
On Nov 22, 2005, at 5:04 PM, Leahy, Kevin wrote: I am defining tiles in tiles-def.xml that user MasterLayout - all working fine using the put tags to inject the components. But I also want tiles where in the tiles definition file I can use the put tags to add components into both the MasterLayout and the FormLayout. I don't quite get what you mean by this. Can you post relevant portions of your tiles-defs file? Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles Again - Can anyone help?
Good Afternoon Kevin- I believe the JspTilesViewHandlerImpl handler will take the defined viewid and then compute the tileID substitute any extension by .tiles Append .tiles for corresponding definition JspTilesViewHandlerImpl must be configured as an application within faces-config.xml check out http://myfaces.apache.org/tomahawk/tiles.html cungantach? Martin- - Original Message - From: Leahy, Kevin [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Tuesday, November 22, 2005 6:04 PM Subject: RE: Tiles Again - Can anyone help? I have had a problem niggling me for a couple of weeks. I keep going back to it and I'm sure there must be a simple solution, but I think I am missing something simple - struts overload, maybe? ;) I have MasterLayout.jsp and FormLayout.jsp. MasterLayout sets out a basic html page, specifying generic components like the title and menu using tiles:insert tags. FormLayout specifies a form, specifying components again using tiles:insert tags. I am defining tiles in tiles-def.xml that user MasterLayout - all working fine using the put tags to inject the components. But I also want tiles where in the tiles definition file I can use the put tags to add components into both the MasterLayout and the FormLayout. I hope this makes sense to someone. I can send more clarification if needed. Can anyone advise on this? -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: 22 November 2005 22:46 To: Struts Users Mailing List Subject: Re: [tiles] On Nov 22, 2005, at 4:42 PM, Wendy Smoak wrote: I have that exact situation where I don't want the menu showing up on a resolution screen. I'm doing it in tiles-defs.xml, so this may not apply, but it works: tiles-definitions definition name=masterPage path=/WEB-INF/jsp/layout/ basicLayout.jsp put name=title value=IRM Web / put name=menubar value=/WEB-INF/jsp/menubar.jsp / put name=footer value=/WEB-INF/jsp/footer.jsp / ... /definition definition name=resolution.page extends=masterPage put name=heading value=Resolution / put name=menubar value= / put name=bodyvalue=/WEB-INF/jsp/resolutionBody.jsp / /definition ... So it does work. How do you use the menubar definition in the JSP page? Are you using the insert tag? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3166 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL messages problem
For the record, here's the general solution as well, for situations
where you can't use the element body like that. First, defining a
scripting variable:
c:set var=msgfmt:message key=msg.key//c:set
x:yyy ... attr=${msg}/
Or, to avoid the scripting variable, you can use jsp:attribute:
c:yyy ...
jsp:attribute name=attr
fmt:message key=msg.key/
/jsp:attribute
/c:yyy
This comes up on the list so often, I think I'll add an FAQ page to the
wiki :-)
L.
Ed Griebel wrote:
I use this idiom all the time to get a message label on a button:
html:submit property=button styleClass=longButton
bean:message key=button.confirm/
/html:submit
You should be able to substitute fmt:message above.
-ed
On 11/22/05, Wendy Smoak [EMAIL PROTECTED] wrote:
On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Ok, today is apparently the day I get to ask a bunch of stupid questions...
Why doesn't this work?
html:submit styleClass=cssButton value=fmt:message
key=labels.loginButton / /
You can't use a JSP tag as attribute of another JSP tag.
Maybe try c:set with the fmt in the body, then use an expression for
the value of html:submit? Which implies the use of the Struts-EL
taglib, which you should be using if you're on Servlet 2.3/JSTL 1.0.
If you haven't already, change the URI in %@ taglib and leave the
prefix as 'html'.
--
Wendy
-
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: JSTL messages problem
On 11/22/05, Laurie Harper [EMAIL PROTECTED] wrote:
For the record, here's the general solution as well, for situations
where you can't use the element body like that. First, defining a
scripting variable:
c:set var=msgfmt:message key=msg.key//c:set
snip/
http://marc.theaimsgroup.com/?l=struts-userm=113269509808314w=2
-Rahul
x:yyy ... attr=${msg}/
Or, to avoid the scripting variable, you can use jsp:attribute:
c:yyy ...
jsp:attribute name=attr
fmt:message key=msg.key/
/jsp:attribute
/c:yyy
This comes up on the list so often, I think I'll add an FAQ page to the
wiki :-)
L.
Ed Griebel wrote:
I use this idiom all the time to get a message label on a button:
html:submit property=button styleClass=longButton
bean:message key=button.confirm/
/html:submit
You should be able to substitute fmt:message above.
-ed
On 11/22/05, Wendy Smoak [EMAIL PROTECTED] wrote:
On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Ok, today is apparently the day I get to ask a bunch of stupid questions...
Why doesn't this work?
html:submit styleClass=cssButton value=fmt:message
key=labels.loginButton / /
You can't use a JSP tag as attribute of another JSP tag.
Maybe try c:set with the fmt in the body, then use an expression for
the value of html:submit? Which implies the use of the Struts-EL
taglib, which you should be using if you're on Servlet 2.3/JSTL 1.0.
If you haven't already, change the URI in %@ taglib and leave the
prefix as 'html'.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tiles Again - Can anyone help?
Hi Here's MasterLayout.jsp ( abridged ) html:html head titletiles:getAsString name=title //title tiles:insert attribute=MenuDefinitions / /head body tiles:insert attribute=body / tiles:insert attribute=MenuInitializer / /body /html:html Here's FormLayout.jsp ( again very abridged ) html:form action=/EventSearch method=GET onsubmit=eventSearchPreSubmit();return validateEventSearchForm(this); table trtdtiles:insert attribute=SecurityFilter //td/tr trtdtiles:insert attribute=SourceFilter //td/tr trtdtiles:insert attribute=FromAndToDateFilter //td/tr /table /html:form In tiles-defs.xml: definition name=tile.base path=/layout/MasterLayout.jsp put name=MenuDefinitions value=/pageComponents/MenuDefinitions.jsp / put name=MenuInitializer value=/pageComponents/MenuInitializer.jsp / /definition definition name=tile.page1 extends=tile.base put name=MenuDefinitions value=/pageComponents/MenuDefinitions.jsp / put name=MenuInitializer value=/pageComponents/MenuInitializer.jsp / put name=body value=/pageComponents/Page1Body.jsp / /definition What I would like is to be able to define some form tiles like this: definition name=tile.form1 ??? put name=MenuDefinitions value=/pageComponents/MenuDefinitions.jsp / put name=MenuInitializer value=/pageComponents/MenuInitializer.jsp / put name=SecurityFilter value=/pageComponents/SecurityFilter.jsp / put name=SourceFilter value=/pageComponents/SourceFilter.jsp / /definition Here I would be injecting components into gaps that are defined in two layouts. The MasterLayout defines where the menu bits go for example. The FormLayout defines where the SecurityFilter, SourceFilter etc go. Really I guess I want to 'nest' the layouts somehow. Is that possible. I really hope you get what I am trying to do? Otherwise I shall just have to live with what I'm doing now which is to reproduce the MasterLayout in the FormLayout which seems wrong to me. Thanks in advance. -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: 22 November 2005 23:21 To: Struts Users Mailing List Subject: Re: Tiles Again - Can anyone help? On Nov 22, 2005, at 5:04 PM, Leahy, Kevin wrote: I am defining tiles in tiles-def.xml that user MasterLayout - all working fine using the put tags to inject the components. But I also want tiles where in the tiles definition file I can use the put tags to add components into both the MasterLayout and the FormLayout. I don't quite get what you mean by this. Can you post relevant portions of your tiles-defs file? Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3167 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tiles Again - Can anyone help?
Hi I just had a quick look at the link. Without looking too much in depth, isn't myfaces a jsf implementation or have I got that wrong? Do I really need to go outside struts and tiles. Learning struts and hibernate at once is already enough for my head. ;) -Original Message- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: 22 November 2005 23:21 To: Struts Users Mailing List Subject: Re: Tiles Again - Can anyone help? Good Afternoon Kevin- I believe the JspTilesViewHandlerImpl handler will take the defined viewid and then compute the tileID substitute any extension by .tiles Append .tiles for corresponding definition JspTilesViewHandlerImpl must be configured as an application within faces-config.xml check out http://myfaces.apache.org/tomahawk/tiles.html cungantach? Martin- - Original Message - From: Leahy, Kevin [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Tuesday, November 22, 2005 6:04 PM Subject: RE: Tiles Again - Can anyone help? I have had a problem niggling me for a couple of weeks. I keep going back to it and I'm sure there must be a simple solution, but I think I am missing something simple - struts overload, maybe? ;) I have MasterLayout.jsp and FormLayout.jsp. MasterLayout sets out a basic html page, specifying generic components like the title and menu using tiles:insert tags. FormLayout specifies a form, specifying components again using tiles:insert tags. I am defining tiles in tiles-def.xml that user MasterLayout - all working fine using the put tags to inject the components. But I also want tiles where in the tiles definition file I can use the put tags to add components into both the MasterLayout and the FormLayout. I hope this makes sense to someone. I can send more clarification if needed. Can anyone advise on this? -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: 22 November 2005 22:46 To: Struts Users Mailing List Subject: Re: [tiles] On Nov 22, 2005, at 4:42 PM, Wendy Smoak wrote: I have that exact situation where I don't want the menu showing up on a resolution screen. I'm doing it in tiles-defs.xml, so this may not apply, but it works: tiles-definitions definition name=masterPage path=/WEB-INF/jsp/layout/ basicLayout.jsp put name=title value=IRM Web / put name=menubar value=/WEB-INF/jsp/menubar.jsp / put name=footer value=/WEB-INF/jsp/footer.jsp / ... /definition definition name=resolution.page extends=masterPage put name=heading value=Resolution / put name=menubar value= / put name=bodyvalue=/WEB-INF/jsp/resolutionBody.jsp / /definition ... So it does work. How do you use the menubar definition in the JSP page? Are you using the insert tag? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3166 -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3166 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upgrade from struts1.0 to 1.2
but I can't find in any document about the removal of the template tag, anybody found that entry? Thanks. On 11/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Have you moved your Action code from the perform() method to the execute() method? - George http://www.idiacomputing.com/ -Original Message- From: bhas4 [mailto:[EMAIL PROTECTED] Sent: Thursday, November 10, 2005 9:20 AM To: user@struts.apache.org Subject: Re:Upgrade from struts1.0 to 1.2 Yes, I have tried everything that is relavent for the upgrade as mentioned in the wiki page - http://wiki.apache.org/struts/StrutsUpgradeNotes11to124, I do not see any wiki pages that talk about upgrade from 1.0 to 1.2 version, could only get 1.1 to 1.2 document. As per the above wiki page, I have done - 1. jars -- using the 1.2 jars required common jar files 2. tlds -- my tlds are defined in web.xml as per the document no change is required I would not be using new features of tld, so no changes done 3. validator.xml -- changed the dtd to point to 1.2 4. validator-rules.xml -- using the new version of .xml file 5. struts-config.xml -- changed the dtd to point to 1.2 verified that I'm not using any of the deprecated attributes 6. ActionError(s) ActionMessage(s) -- I have some usage of ActionError, but not changed yet --- NOT SURE if this will lead to the problem I'm facing. 7. Custom Tags Validation -- I have some usage of RequestUtils ResponseUtil, not changed yet -- but see these classes still exist in struts 1.2, IS THIS causing the issue for me? 8. init-param web.xml -- removed the attributes that are not supported any more added the required one application to my struts-config.xml under message-resources 9. html:form -- I have not used any of the tags that are deprecated 10. MessageResource bundle requirement -- I have not done this step, could this be leading to the issue?? -Bhaskar -- -- Broadband interface (RIA) + mail box saftey = a href=http://Struts_User_List.roomity.com;Struts_User_List.ro omity.com http://omity.com/a *Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131632395152~~ -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yujun Liang [EMAIL PROTECTED]
Re: JSTL messages problem
Well, I said this was the gereral solution ;-) But yes, I forgot about
that, which makes things that bit simpler for this case.
L.
Rahul Akolkar wrote:
On 11/22/05, Laurie Harper [EMAIL PROTECTED] wrote:
For the record, here's the general solution as well, for situations
where you can't use the element body like that. First, defining a
scripting variable:
c:set var=msgfmt:message key=msg.key//c:set
snip/
http://marc.theaimsgroup.com/?l=struts-userm=113269509808314w=2
-Rahul
x:yyy ... attr=${msg}/
Or, to avoid the scripting variable, you can use jsp:attribute:
c:yyy ...
jsp:attribute name=attr
fmt:message key=msg.key/
/jsp:attribute
/c:yyy
This comes up on the list so often, I think I'll add an FAQ page to the
wiki :-)
L.
Ed Griebel wrote:
I use this idiom all the time to get a message label on a button:
html:submit property=button styleClass=longButton
bean:message key=button.confirm/
/html:submit
You should be able to substitute fmt:message above.
-ed
On 11/22/05, Wendy Smoak [EMAIL PROTECTED] wrote:
On 11/22/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Ok, today is apparently the day I get to ask a bunch of stupid questions...
Why doesn't this work?
html:submit styleClass=cssButton value=fmt:message
key=labels.loginButton / /
You can't use a JSP tag as attribute of another JSP tag.
Maybe try c:set with the fmt in the body, then use an expression for
the value of html:submit? Which implies the use of the Struts-EL
taglib, which you should be using if you're on Servlet 2.3/JSTL 1.0.
If you haven't already, change the URI in %@ taglib and leave the
prefix as 'html'.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-dialogs on maven repo
Nicolas, thanks for taking care of that. Looks fine to me. Maybe the only thing is dependency on Struts 1.2.8. In reality, the library should work with 1.2.2 (worked last time I checked couple of months ago), and it definetely works with 1.2.4. Otherwise, looks good. Michael. On 11/22/05, Nicolas De Loof [EMAIL PROTECTED] wrote: I've allready made maven upload requests and build upload bundles. I've created upload bundles for struts-dialogs artifact and set JIRA issues : http://jira.codehaus.org/browse/MAVENUPLOAD-599 http://jira.codehaus.org/browse/MAVENUPLOAD-600 You may add comment to this issue if bundles seems invalid to you. Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upgrade from struts1.0 to 1.2
On 11/22/05, Yujun Liang [EMAIL PROTECTED] wrote: but I can't find in any document about the removal of the template tag, anybody found that entry? The template taglib was deprecated in Struts 1.1 and removed in Struts 1.2. * http://struts.apache.org/struts-doc-1.1/userGuide/dev_template.html So far, we have documented the steps from version to version+1, but not from version to version+2. If someone wants to put something like that together, as Wendy suggested, that would be great. The way to approach it would be to start with the 1.0 to 1.1 notes and then accumulate the 1.1 to 1.2 notes (and soon the 1.2. to 1.3 notes). * http://wiki.apache.org/struts/StrutsUpgradeNotes10to12 Items like the removal of perform were documented when they happened, but not documented again in later release notes. The upgrade notes for 1.1 to 1.2 do not mention things like removing perform, since that should be have been done when upgrading from 1.0 to 1.1. * http://struts.apache.org/struts-doc-1.1/userGuide/release-notes.html -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
why cant the struts action class provide a getSession() api ?
Hi,
I believe supporting a getSession() call is useful in the Action class.
let me walk you through a situation:
public class MyAppBaseAction extends DispatchAction
{
//some helper functions
isAuthorized( arguments )
{
}
}
public class MyAction1 extends MyAppBaseAction
{
create()
{
isAuthorized(...)
//restOfCode
}
}
Now in the above scenario... isAuthorized necessarily needs to be sent a
request object as one of the parameters from which it can extract the
session and then extract the user object from the session. This is not a
great pain, but I think the code would look cleaner if I dont have to pass
the request/session object around. If I had a getSession function support
from the struts action class, then isAuthorized doesnt need to have an
argument like Session or Request.
What do you think?
Regards,
Raghu
Re: why cant the struts action class provide a getSession() api ?
A single instance of each Action class is used to service multiple
simultaneous requests (just like a Servlet). If you want the session,
you have to pass it around (or pass the request around, from which you
can navigate to the session).
Having a no-argument getSession() method on Action would require a
unique Action instance for each request (or Action instance pooling, or
thread-local trickery).
-Max
On Wed, 2005-11-23 at 07:14 +0530, Raghu Kanchustambham wrote:
Hi,
I believe supporting a getSession() call is useful in the Action class.
let me walk you through a situation:
public class MyAppBaseAction extends DispatchAction
{
//some helper functions
isAuthorized( arguments )
{
}
}
public class MyAction1 extends MyAppBaseAction
{
create()
{
isAuthorized(...)
//restOfCode
}
}
Now in the above scenario... isAuthorized necessarily needs to be sent a
request object as one of the parameters from which it can extract the
session and then extract the user object from the session. This is not a
great pain, but I think the code would look cleaner if I dont have to pass
the request/session object around. If I had a getSession function support
from the struts action class, then isAuthorized doesnt need to have an
argument like Session or Request.
What do you think?
Regards,
Raghu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upgrade from struts1.0 to 1.2
Well, the change to template was not mentioned in these documents and I expected to find it there, since it was major change. http://struts.apache.org/struts-doc-1.1/userGuide/release-notes.html http://struts.apache.org/struts-doc-1.2.4/userGuide/release-notes.html Template was my best friend. :) Regards On 11/23/05, Ted Husted [EMAIL PROTECTED] wrote: On 11/22/05, Yujun Liang [EMAIL PROTECTED] wrote: but I can't find in any document about the removal of the template tag, anybody found that entry? The template taglib was deprecated in Struts 1.1 and removed in Struts 1.2. * http://struts.apache.org/struts-doc-1.1/userGuide/dev_template.html So far, we have documented the steps from version to version+1, but not from version to version+2. If someone wants to put something like that together, as Wendy suggested, that would be great. The way to approach it would be to start with the 1.0 to 1.1 notes and then accumulate the 1.1 to 1.2 notes (and soon the 1.2. to 1.3 notes). * http://wiki.apache.org/struts/StrutsUpgradeNotes10to12 Items like the removal of perform were documented when they happened, but not documented again in later release notes. The upgrade notes for 1.1 to 1.2 do not mention things like removing perform, since that should be have been done when upgrading from 1.0 to 1.1. * http://struts.apache.org/struts-doc-1.1/userGuide/release-notes.html -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yujun Liang [EMAIL PROTECTED]
Re: why cant the struts action class provide a getSession() api ?
On 11/22/05, Max Cooper [EMAIL PROTECTED] wrote:
A single instance of each Action class is used to service multiple
simultaneous requests (just like a Servlet). If you want the session,
you have to pass it around (or pass the request around, from which you
can navigate to the session).
Having a no-argument getSession() method on Action would require a
unique Action instance for each request (or Action instance pooling, or
thread-local trickery).
Max is correct ... however the alternative would be to implement the method
like this:
protected HttpSession(HttpServletRequest request) {
return request.getSession();
}
Of course, that's so simple that there is not much value add in providing a
helper method for it. Seems simpler just to call request.getSession()
yourself.
-Max
Craig
RE: Tiles Again - Can anyone help?
Kevin, I think you are correct in that someone hijacked your thread and went JSF(MyFaces) on you.And now, back to your topic: Tiles within Struts... To dynamically alter the components of a Tile definition, I recommend using a Tiles Controller. That should allow you to add or remove components to a tile, like having manual control over a put ... / tag. Tiles controllers can be used as replacement to an Action class or specified in the tile definition itself for that extra self-control (so to speak). For more information, I recommend reading the tilesAdvancedFeatures.pdf link under the Documentation section of the page (scroll down) over at http://www.lifl.fr/~dumoulin/tiles Regards, David -Original Message- From: Leahy, Kevin [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 6:45 PM To: 'Struts Users Mailing List' Subject: RE: Tiles Again - Can anyone help? Hi I just had a quick look at the link. Without looking too much in depth, isn't myfaces a jsf implementation or have I got that wrong? Do I really need to go outside struts and tiles. Learning struts and hibernate at once is already enough for my head. ;) -Original Message- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: 22 November 2005 23:21 To: Struts Users Mailing List Subject: Re: Tiles Again - Can anyone help? Good Afternoon Kevin- I believe the JspTilesViewHandlerImpl handler will take the defined viewid and then compute the tileID substitute any extension by .tiles Append .tiles for corresponding definition JspTilesViewHandlerImpl must be configured as an application within faces-config.xml check out http://myfaces.apache.org/tomahawk/tiles.html cungantach? Martin- - Original Message - From: Leahy, Kevin [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Tuesday, November 22, 2005 6:04 PM Subject: RE: Tiles Again - Can anyone help? I have had a problem niggling me for a couple of weeks. I keep going back to it and I'm sure there must be a simple solution, but I think I am missing something simple - struts overload, maybe? ;) I have MasterLayout.jsp and FormLayout.jsp. MasterLayout sets out a basic html page, specifying generic components like the title and menu using tiles:insert tags. FormLayout specifies a form, specifying components again using tiles:insert tags. I am defining tiles in tiles-def.xml that user MasterLayout - all working fine using the put tags to inject the components. But I also want tiles where in the tiles definition file I can use the put tags to add components into both the MasterLayout and the FormLayout. I hope this makes sense to someone. I can send more clarification if needed. Can anyone advise on this? -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: 22 November 2005 22:46 To: Struts Users Mailing List Subject: Re: [tiles] On Nov 22, 2005, at 4:42 PM, Wendy Smoak wrote: I have that exact situation where I don't want the menu showing up on a resolution screen. I'm doing it in tiles-defs.xml, so this may not apply, but it works: tiles-definitions definition name=masterPage path=/WEB-INF/jsp/layout/ basicLayout.jsp put name=title value=IRM Web / put name=menubar value=/WEB-INF/jsp/menubar.jsp / put name=footer value=/WEB-INF/jsp/footer.jsp / ... /definition definition name=resolution.page extends=masterPage put name=heading value=Resolution / put name=menubar value= / put name=bodyvalue=/WEB-INF/jsp/resolutionBody.jsp / /definition ... So it does work. How do you use the menubar definition in the JSP page? Are you using the insert tag? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
struts-faces and Tiles
I'm trying to get JSF working in my Struts app using the struts-faces integration library. I have everything set up per the readme that comes with struts-faces. I can successfully load foo.jsp with the URL foo.faces, so I think things are configured correctly. However, as soon as I change the definition of any layout in tiles-defs.xml from .jsp to .faces, I get an exception from tiles:get / tiles:insert. As a sanity check, I tried with both MyFaces and the reference implementation. Is this a known limitation or is there something I have to change to make this work? I took a look at Section 9.2.8 of the JSF spec (as mentioned in the struts-faces README) to see if I was running afowl of anything there but it doesn't seem relevant given that I haven't actually changed the JSPs to use any Faces tags yet... L. [Using the JSF RI] ERROR [http-8080-Processor25] ContainerBase.[Catalina].[localhost].[/].[action] - Servlet.service() for servlet action threw exception java.lang.IllegalStateException: Cannot forward after response has been committed at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:313) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:147) at org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:966) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:604) at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:99) at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:135) at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:760) at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:892) at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:462) at org.apache.jsp.pages.core.layout_jsp._jspx_meth_tiles_get_0(org.apache.jsp.pages.core.layout_jsp:771) at org.apache.jsp.pages.core.layout_jsp._jspService(org.apache.jsp.pages.core.layout_jsp:341) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:147) at org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at
Re: [shale] Design questions
I kind of agree with you Gary. I just love Tiles powerful features and I would like to use it in my JSF application (but I would take a deep look at Tapestry way of doing it to see if it is truly necessary). Anyway, I started to have concerns after watching the JavaOne 2005 presentation Extreme Reuse in JavaServer Faces, TS-7853 (wich was very interesting by the way). There seems to be a lot of non-obvious concerns when using non-JSF aware technologies for the layout of a JSF view. I know that Shale provides an integration ViewHandler for Tiles wich allow him to resolve .pages urls and eliminates the need for stupid jsp wrappers but I think it resolves only part of the problem. Here's a small summary of the main issues for those who don't have time to watch the presentation. First, even if it's not such a huge concern but still have to be taken in account when designing the application, navigation rules are relative to the top viewid and not the tile itself. It can be a bit confusing but I guess you can find your way around it. Second, you can't use some more advanced Tiles functionnalities like importAttributes (see the presentation). Again you are sticking to a basic usage, I still think Tiles can be a valid solution. But the main problem come from the fact that Tiles is for the moment not a solution specific to JSF technology and provides no adapters for this framework. Therefore, a tile is sadly not a JSF UI component. It's mean that JSF Beans can't see your application tiles. You can say goodbye to the use of the binding attribute and so managing some of your UI components programmaticaly is impossible. This is a huge limitation in my opinion. Maybe Shale already solves those issues but from what I have read on the Javadoc page, it doesn't seem to. I think people should be aware of those issues to make a discern choice. Just my two cents. I'll be glad to hear any nice solutions to those problems if someone has any ideas. *By the way, the Rolodex use case seems to be broken for the moment except for the jsp example. Both of the Html views and the Xml view output span class=@class around every element. For example, the first line is shown like this span ...html/span (IE is able to render the page but not Firefox of course :)). On 11/22/05, Gary VanMatre [EMAIL PROTECTED] wrote: Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. I'm a big fan of Tiles and think that Clay and Tiles have their own niches. I see tiles as a tool for assembling page fragments in a reusable way. Clay is at a more granular level. It's focus is on assembling a page of reusable widgets. There are many ways to use Clay but I'll give the following example of inheritance and composition. component jsfid=baseInputText extends=inputText attributes !-- Convention mapping class attribute to styleClass property -- set name=styleClass value=@class/ /attributes symbols set name=class value=generic / /symbols /component component jsfid=panel extends=panelGrid element jsfid=baseInputText renderid=0 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=blue / /symbols /element element jsfid=baseInputText renderid=1 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=green / /symbols /element /component Elements form composition but also add inheritance similar to a java inner class. The new symbol replacement is sort of a tiles like feature where you can customize by overriding a symbol value. PS: I'm on vacation this week and have limited Internet access. Hermod Gary -- Alexandre Poitras Québec, Canada
Re: struts-faces and Tiles
Correction: the problem occurs when I change a nested tile to .faces instead of .jsp. Changing *only* the containing layout tile's definition seems to work. However, I have to include f:view in the nested JSP; including it in the layout doesn't seem to be sufficient, which makes me think using UI components in the layout may prove troublesome... Still, this gets me far enough to continue playing :-) L. Laurie Harper wrote: I'm trying to get JSF working in my Struts app using the struts-faces integration library. I have everything set up per the readme that comes with struts-faces. I can successfully load foo.jsp with the URL foo.faces, so I think things are configured correctly. However, as soon as I change the definition of any layout in tiles-defs.xml from .jsp to .faces, I get an exception from tiles:get / tiles:insert. As a sanity check, I tried with both MyFaces and the reference implementation. Is this a known limitation or is there something I have to change to make this work? I took a look at Section 9.2.8 of the JSF spec (as mentioned in the struts-faces README) to see if I was running afowl of anything there but it doesn't seem relevant given that I haven't actually changed the JSPs to use any Faces tags yet... L. [Using the JSF RI] ERROR [http-8080-Processor25] ContainerBase.[Catalina].[localhost].[/].[action] - Servlet.service() for servlet action threw exception java.lang.IllegalStateException: Cannot forward after response has been committed at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:313) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:147) at org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:966) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:604) at org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:99) at org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:135) at org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:760) at org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:892) at org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:462) at org.apache.jsp.pages.core.layout_jsp._jspx_meth_tiles_get_0(org.apache.jsp.pages.core.layout_jsp:771) at org.apache.jsp.pages.core.layout_jsp._jspService(org.apache.jsp.pages.core.layout_jsp:341) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:147) at org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) at
Re: access rights for JAR
If you're using (or are willing to use) container managed security, Nick's suggestion will work for that scenario. Add a security constraint to your web.xml for the applet JAR. If you can't use container managed security, you'll have to get rather more fancy, for example by providing a servlet to serve up the applet and storing the JAR somewhere under WEB-INF to prevent direct access. L. Deepa Khetan wrote: Well, The exact problem is, my Applet.jar gets downloaded at the client side, on request. But any person who knows the path of this JAR file, on the server, can download this JAR. So, i was just thinking, if i can specify somewhere that this JAR canot be downloaded unless an Authenticated user tries to do it. It needs to be downloaded only after a person logs into the system and clicks on the function to Upload Files( For which this JAR gets downloaded). Deepa On 11/22/05, Nick Sophinos [EMAIL PROTECTED] wrote: I imagine that the same mechanism that protects a web directory would work. One example would be to specify in the web.xml for the container to protect a given directory with authentication. See any book on servlets or JSP about that one. There are more sophisticated ways, but given the general nature of your question, I would start with that general solution. - Nick On 11/22/05, Deepa Khetan [EMAIL PROTECTED] wrote: Can i specify in my Config Files(web.xml or struts-config.xml) that a JAR file cannot be downloaded without logging into the system?? Regards, Deepa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javascript in validator
fea jabi wrote: One of the requirement in my application is that I should not use the client side javascript as the browsers the user use might not have the javascript enabled in their browsers. In my jsp there are 2 radio buttons. one of which is enable by default. When the user clicks on either of those he/she should be promted with some message depending on which radio button they pressed Yes/No. Using DynaValidatorForm. Can I do this in struts validator xml? if so how to do this? No, validator can check if a form is valid but it doesn't provide a way to generate arbitrary prompts and dialogs. Assuming you want something like an 'Are you sure you want to change this option? yes/no' prompt, you'll need to do that as a separate page. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why cant the struts action class provide a getSession() api ?
Thanks Max and Craig for your responses.
I agree with the overheads of pooling a stateful entity probably doesn't
justify its inclusion.
I was not looking for an api which gives me a session object after taking
the request object as an input parameter which as Craig points out is too
simplistic.
However, lets go by the Threadlocal trickery. It may be a little tricky..
but then the regular struts user doesnt have to worry about it. It can be
implemented under the hood .. unless someone tells me its again going to be
a performance overhead to do it under the hood.
Going back to the specific use case I was referring to... I do not like
passing the 'user' object around. The code is executing in the context of
the user and any function written in the action class should have access to
it. Note that I dont like passing around the request/session object either
(if it can be got through a call like getSession() or getRequest()
dont know if I am missing something somewhere... but should not this be
possible through ThreadLocal?
Regards,
Raghu
On 11/23/05, Craig McClanahan [EMAIL PROTECTED] wrote:
On 11/22/05, Max Cooper [EMAIL PROTECTED] wrote:
A single instance of each Action class is used to service multiple
simultaneous requests (just like a Servlet). If you want the session,
you have to pass it around (or pass the request around, from which you
can navigate to the session).
Having a no-argument getSession() method on Action would require a
unique Action instance for each request (or Action instance pooling, or
thread-local trickery).
Max is correct ... however the alternative would be to implement the
method
like this:
protected HttpSession(HttpServletRequest request) {
return request.getSession();
}
Of course, that's so simple that there is not much value add in providing
a
helper method for it. Seems simpler just to call request.getSession()
yourself.
-Max
Craig
RE: [shale] Design questions
Hi Forgotten the basics of Tiles, have we? One of the key features of Tiles is the term definition and template jsp. In the template jsp, you position named generic parts. In the the definition you define what those parts are. This, in my terms, is to compose a page, hence composition. Another key feature of Tiles is that you can define a definition B which extends definition A. In definition B you can override attributes of definitoin A. This, in my terms, is inheritance. SFTH Hermod -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 4:05 PM To: Struts Users Mailing List Subject: Re: [shale] Design questions Composition is a preferred design instead of inheritance. So, implementing composition, with inheritance does not make much sense. On 11/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Craig McClanahan Sent: Tuesday, November 22, 2005 6:15 AM To: Struts Users Mailing List Subject: Re: [shale] Design questions On 11/21/05, Alexandre Poitras [EMAIL PROTECTED] wrote: Hi! First of all, congratz on the good job. Shale looks very promising. We are currently implementing JSF in my organization. I already knew about Shale but I hadn't checked its progress in a while and I must say I am impressed so far. Actually, I stumbled upon the project while I was looking for a way to build in a quick way new UI components. The idea of creating 3 different classes each time to be able to aggregate some already existing UI components didn't sound particulary attractive. And that's how I found the goodies of Shale. Welcome! Anyway, to make it short, I am experimenting Clay's feature right now but I am a little bit confused. There seems to be a bit of overlap between Tiles and Clay features? Am I correct? And if it's true, is it a better choice to keep using Tiles as my layout manager or should I do it the Tapestry's way and treat everything as a UI component with the help of Clay? Clay is ... um, err ... pretty malleable :-). And yes, from the point of view of layout templating, there is definitely overlap. Tiles support has been a highly requested capability for JSF based applications, primarily because existing Struts developers are comfortable with it, and being able to reuse that capability meant a little bit less of an initial learning curve was necessary. My personal feeling is that Clay (or a similar project at java.net http://java.net http://java.net called facelets) will become more popular for people coming to JSF without a large Struts legacy. The approach is more flexible and fine grained, and it wouldn't surprise me if we can make it perform better as well since it omits the need to use the container's RequestDispatcher.include() functionality. Another thought that keeps rambling through my head is a question concerning the backing beans design. I have red on many blogs entries that one of the greatest strength of JSF is the fact that the backing beans don't have to implements any interfaces. But if you want to take advantage of Shake page level services infrastructure (the view package), your beans have to implement the ViewController interface. Don't get me wrong, I think those services are great tools but I was wondering if all the beans should be ViewController instances or just when it is absolutly necessary? My personal habit is to use the interfaces all the time ... then I can focus my attention on the event driven parts of the design, and never run into situations where I define an init() method later, but it never gets called ... because I forgot to add implements ViewController up at the top of the class. Even better, if you're going to commit to doing this anyway, is to extends AbstractViewController instead of implements ViewController. Not only does this give you a bit of protection if ViewController ever changes, it also gives you a bunch of other nice convenience methods that makes things like the programmatic evaluation of value binding expressions much easier. One of the reasons people tout the no required interfaces possibility in JSF as an advantage is that it makes backing beans much easier to build unit tests for. However, Shale's approach is to protect this testability advantage, while still giving you the usability advantages of the extra events. It even includes a test framework to help you build unit tests for your view controllers very easily. Finally, another concern I have with this approach is that it's kind of suggesting you to write one bean for each page of the application (using a 1:1 mapping). From all the research I have done in the JSF area, I have not been able to find a consensus
RE: [shale] Design questions
Hi Thanks for your clarification Craig. So, if I read you correct, Tiles and Clay go hand in hand. Use Tiles for assembling the pages, so that you only have to write jsp/html files containing the specific content (not the whole page). Then use Clay to do the work writing of the jsp/html files them self, utilizing Clay component definitions and their corresponding jsfid's in those pages. Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 11:49 PM To: Struts Users Mailing List Subject: RE: [shale] Design questions Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. I'm a big fan of Tiles and think that Clay and Tiles have their own niches. I see tiles as a tool for assembling page fragments in a reusable way. Clay is at a more granular level. It's focus is on assembling a page of reusable widgets. There are many ways to use Clay but I'll give the following example of inheritance and composition. component jsfid=baseInputText extends=inputText attributes !-- Convention mapping class attribute to styleClass property -- set name=styleClass value=@class/ /attributes symbols set name=class value=generic / /symbols /component component jsfid=panel extends=panelGrid element jsfid=baseInputText renderid=0 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=blue / /symbols /element element jsfid=baseInputText renderid=1 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=green / /symbols /element /component Elements form composition but also add inheritance similar to a java inner class. The new symbol replacement is sort of a tiles like feature where you can customize by overriding a symbol value. PS: I'm on vacation this week and have limited Internet access. Hermod Gary * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] Design questions
Hi That should of course read: Thanks for your clarification -Gary- Sorry ! Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 23, 2005 6:25 AM To: user@struts.apache.org Subject: RE: [shale] Design questions Hi Thanks for your clarification Craig. So, if I read you correct, Tiles and Clay go hand in hand. Use Tiles for assembling the pages, so that you only have to write jsp/html files containing the specific content (not the whole page). Then use Clay to do the work writing of the jsp/html files them self, utilizing Clay component definitions and their corresponding jsfid's in those pages. Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 11:49 PM To: Struts Users Mailing List Subject: RE: [shale] Design questions Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. I'm a big fan of Tiles and think that Clay and Tiles have their own niches. I see tiles as a tool for assembling page fragments in a reusable way. Clay is at a more granular level. It's focus is on assembling a page of reusable widgets. There are many ways to use Clay but I'll give the following example of inheritance and composition. component jsfid=baseInputText extends=inputText attributes !-- Convention mapping class attribute to styleClass property -- set name=styleClass value=@class/ /attributes symbols set name=class value=generic / /symbols /component component jsfid=panel extends=panelGrid element jsfid=baseInputText renderid=0 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=blue / /symbols /element element jsfid=baseInputText renderid=1 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=green / /symbols /element /component Elements form composition but also add inheritance similar to a java inner class. The new symbol replacement is sort of a tiles like feature where you can customize by overriding a symbol value. PS: I'm on vacation this week and have limited Internet access. Hermod Gary * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - 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: [shale] Design questions
Alexandre, If you're looking for a JSF aware template technology, I recommend you look at facelets (https://facelets.dev.java.net). Regards, David -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 11:17 PM To: Struts Users Mailing List Subject: Re: [shale] Design questions I kind of agree with you Gary. I just love Tiles powerful features and I would like to use it in my JSF application (but I would take a deep look at Tapestry way of doing it to see if it is truly necessary). Anyway, I started to have concerns after watching the JavaOne 2005 presentation Extreme Reuse in JavaServer Faces, TS-7853 (wich was very interesting by the way). There seems to be a lot of non-obvious concerns when using non-JSF aware technologies for the layout of a JSF view. I know that Shale provides an integration ViewHandler for Tiles wich allow him to resolve .pages urls and eliminates the need for stupid jsp wrappers but I think it resolves only part of the problem. Here's a small summary of the main issues for those who don't have time to watch the presentation. First, even if it's not such a huge concern but still have to be taken in account when designing the application, navigation rules are relative to the top viewid and not the tile itself. It can be a bit confusing but I guess you can find your way around it. Second, you can't use some more advanced Tiles functionnalities like importAttributes (see the presentation). Again you are sticking to a basic usage, I still think Tiles can be a valid solution. But the main problem come from the fact that Tiles is for the moment not a solution specific to JSF technology and provides no adapters for this framework. Therefore, a tile is sadly not a JSF UI component. It's mean that JSF Beans can't see your application tiles. You can say goodbye to the use of the binding attribute and so managing some of your UI components programmaticaly is impossible. This is a huge limitation in my opinion. Maybe Shale already solves those issues but from what I have read on the Javadoc page, it doesn't seem to. I think people should be aware of those issues to make a discern choice. Just my two cents. I'll be glad to hear any nice solutions to those problems if someone has any ideas. *By the way, the Rolodex use case seems to be broken for the moment except for the jsp example. Both of the Html views and the Xml view output span class=@class around every element. For example, the first line is shown like this span ...html/span (IE is able to render the page but not Firefox of course :)). On 11/22/05, Gary VanMatre [EMAIL PROTECTED] wrote: Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. I'm a big fan of Tiles and think that Clay and Tiles have their own niches. I see tiles as a tool for assembling page fragments in a reusable way. Clay is at a more granular level. It's focus is on assembling a page of reusable widgets. There are many ways to use Clay but I'll give the following example of inheritance and composition. component jsfid=baseInputText extends=inputText attributes !-- Convention mapping class attribute to styleClass property -- set name=styleClass value=@class/ /attributes symbols set name=class value=generic / /symbols /component component jsfid=panel extends=panelGrid element jsfid=baseInputText renderid=0 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=blue / /symbols /element element jsfid=baseInputText renderid=1 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=green / /symbols /element /component Elements form composition but also add inheritance similar to a java inner class. The new symbol replacement is sort of a tiles like feature where you can customize by overriding a symbol value. PS: I'm on vacation this week and have limited Internet access. Hermod Gary -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] Design questions
Hi Alexandre Mostly I aboslutly agree with you, but there is one thing that I am not comfortable with: ..and so managing some of your UI components programmaticaly is impossible. What you are promoting here, is mixing view and controller, but since Craig is promoting the use of one backing bean pr. view (page?), this may or may not be viable. Allthough I do not think that the thought behind it is what you want. One of the things that I do not like is that we might be getting into a situation here where we have some of the logic for creating a page in xml definition files, and some of it in code (as you want to do). This may lead us into a situation where we may kind of loose sight of as to where things get defined. I think that it is a cleaner aproach to have things in one place, and not scatter it around. Just my 2c worth. I recently posted a suggestion that the backing beans (ViewControllers) be bound to .jsp pages, and not to URI's when using Tiles. As far as I can see I have not got a clear answer to this. This goes exactly to the problem at hand here: Tiles. Since the individual tiles may be reused in many pages, not having the ability to do prerender on the tiles, but only on the page kind of defeats the purpose of Tiles. It means you are going to have to duplicate code in variuos backing beans. It would be really nice to have it as Winny the poo: Yes, please. I.e both on pages and on .jsps (tiles). I guess one way of solving it would be to implement something portal like. Hermod -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 23, 2005 5:17 AM To: Struts Users Mailing List Subject: Re: [shale] Design questions I kind of agree with you Gary. I just love Tiles powerful features and I would like to use it in my JSF application (but I would take a deep look at Tapestry way of doing it to see if it is truly necessary). Anyway, I started to have concerns after watching the JavaOne 2005 presentation Extreme Reuse in JavaServer Faces, TS-7853 (wich was very interesting by the way). There seems to be a lot of non-obvious concerns when using non-JSF aware technologies for the layout of a JSF view. I know that Shale provides an integration ViewHandler for Tiles wich allow him to resolve .pages urls and eliminates the need for stupid jsp wrappers but I think it resolves only part of the problem. Here's a small summary of the main issues for those who don't have time to watch the presentation. First, even if it's not such a huge concern but still have to be taken in account when designing the application, navigation rules are relative to the top viewid and not the tile itself. It can be a bit confusing but I guess you can find your way around it. Second, you can't use some more advanced Tiles functionnalities like importAttributes (see the presentation). Again you are sticking to a basic usage, I still think Tiles can be a valid solution. But the main problem come from the fact that Tiles is for the moment not a solution specific to JSF technology and provides no adapters for this framework. Therefore, a tile is sadly not a JSF UI component. It's mean that JSF Beans can't see your application tiles. You can say goodbye to the use of the binding attribute and so managing some of your UI components programmaticaly is impossible. This is a huge limitation in my opinion. Maybe Shale already solves those issues but from what I have read on the Javadoc page, it doesn't seem to. I think people should be aware of those issues to make a discern choice. Just my two cents. I'll be glad to hear any nice solutions to those problems if someone has any ideas. *By the way, the Rolodex use case seems to be broken for the moment except for the jsp example. Both of the Html views and the Xml view output span class=@class around every element. For example, the first line is shown like this span ...html/span (IE is able to render the page but not Firefox of course :)). On 11/22/05, Gary VanMatre [EMAIL PROTECTED] wrote: Hi So how would you implement composition, with inheritance, using Clay instead of Tiles?. I'm a big fan of Tiles and think that Clay and Tiles have their own niches. I see tiles as a tool for assembling page fragments in a reusable way. Clay is at a more granular level. It's focus is on assembling a page of reusable widgets. There are many ways to use Clay but I'll give the following example of inheritance and composition. component jsfid=baseInputText extends=inputText attributes !-- Convention mapping class attribute to styleClass property -- set name=styleClass value=@class/ /attributes symbols set name=class value=generic / /symbols /component component jsfid=panel extends=panelGrid element jsfid=baseInputText renderid=0 attributes set name=value value=[EMAIL PROTECTED]/ /attributes symbols set name=class value=blue / /symbols /element element jsfid=baseInputText renderid=1
Interesting!
Hello Friends, I have developed a module in my Project to Make changes in the resource Bundle (.properties) file at RunTime by Using java.io.After Writing on a File(Through Action Action Class) the web Server gets Restarted the updated Resource Bundle is Displayed on a JSP.(after Refreshing that Page) As the Web Server gets started for Every change I have made,i have stored the entire changes in a Temporary File (which is different from my current Resource Bundle properties). My Intention is to load that file(temporary file) Through Action Servlet(we are having extended Action Servlet of ours in Application).How can i do this? Please Guide! Regards, Shailesh Barde
Inserting special character into MySQL 5 problem
Hello! I'm having very strange problem :-( I'm using CharacterEncodingFilter set to work with utf-8 encoding (response and request) and when testing aplication geting: 08:29:42,970 INFO [STDOUT] RESPONSE character encoding= utf-8 08:29:42,970 INFO [STDOUT] REQUEST character encoding= UTF-8 08:29:42,970 INFO [STDOUT] JVM encoding Cp1250 MySQL is set also to utf-8 encoding, but when I'm trying to import data into tabel from struts I get only one part of the letters (I'm from Croatia and we have 5 special letters: šđčćž). But when I'm using SQL insert directly into MySQL query I get everything O.K.? Does anyone knows what seem to be problem? Tnx, Stanislav PS: Using: struts 1.2.7, J2EE 1.4 SDK, JBoss 4.0.1, MySQL 5.0.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
