RE: Clay templating
Hi This is what templating is all about. You create one base layout that all you pages are based on. It will normally be divided into several reusabloe sections, such as footer, jheader, menu and contents (as in your scenario). Now when you create new pages, the only thing you want to create is the stuff that changes (normally the content) and not have to create a complete page with every thing on it each time. You do not need the start.thml, only the startBody.html The what you do is in clay-views-config (assuming you have followed the standard) you define: component jsfid=/start.html extends basePage symbols set name=@title value=Application Home / set name=@bodycontent value=/startBody.html / /symbols /component As you can see this is very close to what you did. (There is a catch here: You need to add .html as something that JSF is supposed to handle in the web.xml file) I have written a getting started tutorial that you can look at: http://wiki.apache.org/shale/ShaleAndClayTutorial Hopefully later to day I'll add another tutorial that goes into basic component creation. Hermod -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 12:15 PM To: 'user@shale.apache.org' Subject: Clay templating Hi all, I use Clay to build my pages with templates. I have a base page, all my actual pages are derived from the base page. My clay-config.xml looks like this component jsfid=basePage extends=clay attributes set name=clayJsfid value=/templates/layout.html / /attributes symbols set name=@title value=Default Title / set name=@headercontent value=/templates/header.html / set name=@bodycontent value=space / set name=@footercontent value=/templates/footer.html / /symbols /component component jsfid=startPage extends=basePage symbols set name=@title value=Application Home / set name=@bodycontent value=/startBody.html / /symbols /component The problem is my actual page start.html it looks like this: span jsfid=startPage/ So the issue I'm having is that for every page I need two files start.html startBody.html The start.html page only calls the startPage clay component. So I'd like to have only one file which contains my body. Are there any possibilties to do this? Thanks Bernhard * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group 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 anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
AW: Clay templating
Rich, thanks for the answer. I use an HTML page not a JSP page (Clay HTML View). This is useful because I don't need to define a separate component for every page. Ist this possible (to set the values of the symbols) for an HTML View too? Bernhard -Ursprüngliche Nachricht- Von: Richard Eggert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 26. Februar 2007 12:30 An: user@shale.apache.org Betreff: RE: Clay templating Let me see if I'm understanding you properly. Do you also have a corresponding JSP page (start.jsp) to load the HTML template? If so, it can contain an element like this: clay:clay jsfid=basePage clay:symbol name=title value=Application Home / clay:symbol name=bodyContent value=/startBody.html / /clay This is instead of doing clay:clay jsfid=startPage / (i.e., startPage isn't strictly necessary). Does this help? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 6:14 AM To: 'user@shale.apache.org' Subject: Clay templating Hi all, I use Clay to build my pages with templates. I have a base page, all my actual pages are derived from the base page. My clay-config.xml looks like this component jsfid=basePage extends=clay attributes set name=clayJsfid value=/templates/layout.html / /attributes symbols set name=@title value=Default Title / set name=@headercontent value=/templates/header.html / set name=@bodycontent value=space / set name=@footercontent value=/templates/footer.html / /symbols /component component jsfid=startPage extends=basePage symbols set name=@title value=Application Home / set name=@bodycontent value=/startBody.html / /symbols /component The problem is my actual page start.html it looks like this: span jsfid=startPage/ So the issue I'm having is that for every page I need two files start.html startBody.html The start.html page only calls the startPage clay component. So I'd like to have only one file which contains my body. Are there any possibilties to do this? Thanks Bernhard
RE: Clay templating
From: Richard Eggert [EMAIL PROTECTED] This directly contradicts one of the things Hermod said in his email (that start.html doesn't have to exist), unless I misunderstood him. Now I'm really confused! Well, you could make the suffix mapping of full XML views to .html and then make the suffix mapping of full HTML views to .fhtml. They just can not be the same. I really wish we would have used other terms than full html and full xml... It's kind of misleading.. I would rather make the full xml view suffix something like .jsf. Hermod's archetype will generate a base project that uses full xml: views [1]. [1] https://svn.apache.org/viewvc/shale/sandbox/maven/archetypes/ Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 11:18 AM To: user@shale.apache.org Subject: Re: Clay templating Html templates use and extend common elements. This type of template can be a fragment or the entire page. If the template is the entry point to the page, it must be a physical resource meaning that it can't be a pseudo tiles like resource that doesn't exist.
RE: Weird error for full HTML views
From: Richard Eggert [EMAIL PROTECTED] I am using the ShaleApplicationFilter. I know it's being called, since it ShaleApplicationFilter.doFilter appears in the stack trace for the error that I'm getting. My chain-config.xml looks identical to the one from the clay-usecases example (minus the commented-out parts). I have a ChainListener configured and I have chain.CONFIG_WEB_RESOURCE pointing to /WEB-INF/chain-config.xml. Is it possible that the MyFaces ExtensionsFilter is somehow interfering with it? If so, is there any way to remedy it? Sorry, I was focusing on the wrong problem before. It look like this getContentType() method is only available in the servlet 2.4. http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletResponse.html#getContentType() Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 11:49 AM To: user@shale.apache.org Subject: Re: Weird error for full HTML views From: Richard Eggert I'm trying to get full HTML views working. I was able to get partial HTML views (using JSP to load the HTML template) working, but I keep getting the same weird error: The full html and full xml views are different animals. If you are using a full HTML view, it must be a physical file similar to JSP. The full XML views allow you to define a config definition as the page entry point but it requires a unique suffix. The default suffix is .html and .xml but can be changed in the web.xml java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getContentType()Ljava/lang/String; at org.apache.shale.faces.ClayViewHandler.renderView(ClayViewHandler.java:385) ... The page I'm trying to load is named /htmlTest.foo and it exists only within my clay-views.xml. I've set FULLXML_CONFIG_FILES to /WEB-INF/clay-views.xml. I've set XML_TEMPLATE_SUFFIX to .foo. I have a filter-mapping for /* to point to the ShaleApplicationFilter that I set up. I have a servlet-mapping that maps *.foo to the Faces servlet. I have a mime-mapping that maps the foo extension to text/html. I have not modified javax.faces.DEFAULT_SUFFIX (i.e., I've left it as the default of .jsp), since I still have a lot of traditional JSP-based JSF pages (I did try changing it to .foo at one point, to no effect). I don't know if it's relevant, but I did notice the following lines in my log file (note the file extensions): org.apache.shale.clay.faces.ClayViewHandler:282 - Clay template restoreView for /htmlTest.jsp org.apache.shale.clay.faces.ClayViewHandler:366 - Clay template renderView for /htmlTest.jsp Does anyone have any idea of why I'm getting this error (or, more importantly, how to fix it)? JSF really only wants you to choose one type of templating. You can mix the three types but you need the shale-application library. What happens is JSF will normalize the view suffix to the javax.faces.DEFAULT_SUFFIX value. There is a preprocess command that is invoked from a filter that captures the view suffix before the normal processing of the viewId. The captured suffix overrides the default. This won't work in a portal environment and I've heard reports of it not working all the time. I covered this in more detail in a resonse to Bernhard's question [1]. The shale-clay-usecases trys to explain the problems too [2]. Unfortunately, you are better off if you choose a single JSF view entry point. [1] http://www.nabble.com/Clay-templating-tf3292202.html (should be here but I just posted the response) [2] https://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecas es/src/main/webapp/usecases.jsp?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
Re: tomahawk-1_1_?-config.xml
From: Richard Eggert [EMAIL PROTECTED] This is probably a dumb question, but is there some way to get Shale to load the tomahawk-1_1_1-config.xml or tomahawk-1_1_3-config.xml file that comes bundeled in shale-clay-*.jar's META-INF, short of extracting the file and putting it in my own WEB-INF or pasting the contents into my own clay-config.xml? I don't see it mentioned anywhere in the examples. There is one example but it's in the sandbox [1]. You need to add classpath*: before the resource name. This works with html templates too. !-- Clay Common Configuration Resources -- context-param param-name org.apache.shale.clay.COMMON_CONFIG_FILES /param-name param-value /WEB-INF/clay-config.xml, classpath*:META-INF/tomahawk-1_1_3-config.xml /param-value /context-param [1] http://svn.apache.org/viewvc/shale/sandbox/shale-clay-mailreader/src/main/webapp/WEB-INF/web.xml?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
Stand alone tiles requirements
I'm looking at SiteMesh or Stand alone tiles with a JSF application running on JVM 1.4.x (WebSphere 6.x). From here: http://struts.apache.org/struts-sandbox/tiles/index.html I see that tiles requires 1.4.x but in looking at the code I see it uses 1.5only features such as Generics. http://svn.apache.org/repos/asf/tiles I can't find a 1.4.x version, is there one? Thanks, Joel
RE: Weird error for full HTML views
From: Richard Eggert [EMAIL PROTECTED] Silly me. The reason it's throwing a NoSuchMethodError on HttpServletResponse.getContentType is that there is no getContentType method in HttpServletResponse - at least not in the ancient version of the Servlets API that I'm using! Man, I hate WebLogic 8.1. It was a mistake to use this method. I had hoped to make clay J2EE 1.3 compliant but I just missed that one. If you are stuck with 8.1, I'll try to find a work around if you create a JIRA ticket. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Richard Eggert [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 12:08 PM To: user@shale.apache.org Subject: RE: Weird error for full HTML views I am using the ShaleApplicationFilter. I know it's being called, since it ShaleApplicationFilter.doFilter appears in the stack trace for the error that I'm getting. My chain-config.xml looks identical to the one from the clay-usecases example (minus the commented-out parts). I have a ChainListener configured and I have chain.CONFIG_WEB_RESOURCE pointing to /WEB-INF/chain-config.xml. Is it possible that the MyFaces ExtensionsFilter is somehow interfering with it? If so, is there any way to remedy it? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 11:49 AM To: user@shale.apache.org Subject: Re: Weird error for full HTML views From: Richard Eggert I'm trying to get full HTML views working. I was able to get partial HTML views (using JSP to load the HTML template) working, but I keep getting the same weird error: The full html and full xml views are different animals. If you are using a full HTML view, it must be a physical file similar to JSP. The full XML views allow you to define a config definition as the page entry point but it requires a unique suffix. The default suffix is .html and .xml but can be changed in the web.xml java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getContentType()Ljava/lang/String; at org.apache.shale.faces.ClayViewHandler.renderView(ClayViewHandler.java:385) ... The page I'm trying to load is named /htmlTest.foo and it exists only within my clay-views.xml. I've set FULLXML_CONFIG_FILES to /WEB-INF/clay-views.xml. I've set XML_TEMPLATE_SUFFIX to .foo. I have a filter-mapping for /* to point to the ShaleApplicationFilter that I set up. I have a servlet-mapping that maps *.foo to the Faces servlet. I have a mime-mapping that maps the foo extension to text/html. I have not modified javax.faces.DEFAULT_SUFFIX (i.e., I've left it as the default of .jsp), since I still have a lot of traditional JSP-based JSF pages (I did try changing it to .foo at one point, to no effect). I don't know if it's relevant, but I did notice the following lines in my log file (note the file extensions): org.apache.shale.clay.faces.ClayViewHandler:282 - Clay template restoreView for /htmlTest.jsp org.apache.shale.clay.faces.ClayViewHandler:366 - Clay template renderView for /htmlTest.jsp Does anyone have any idea of why I'm getting this error (or, more importantly, how to fix it)? JSF really only wants you to choose one type of templating. You can mix the three types but you need the shale-application library. What happens is JSF will normalize the view suffix to the javax.faces.DEFAULT_SUFFIX value. There is a preprocess command that is invoked from a filter that captures the view suffix before the normal processing of the viewId. The captured suffix overrides the default. This won't work in a portal environment and I've heard reports of it not working all the time. I covered this in more detail in a resonse to Bernhard's question [1]. The shale-clay-usecases trys to explain the problems too [2]. Unfortunately, you are better off if you choose a single JSF view entry point. [1] http://www.nabble.com/Clay-templating-tf3292202.html (should be here but I just posted the response) [2] https://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecas es/src/main/webapp/usecases.jsp?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
RE: Weird error for full HTML views
Yeah. Upgrading to WebLogic 9.2 fixed the problem. Thanks anyway, though. :-) Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 4:53 PM To: user@shale.apache.org Subject: RE: Weird error for full HTML views From: Richard Eggert [EMAIL PROTECTED] I am using the ShaleApplicationFilter. I know it's being called, since it ShaleApplicationFilter.doFilter appears in the stack trace for the error that I'm getting. My chain-config.xml looks identical to the one from the clay-usecases example (minus the commented-out parts). I have a ChainListener configured and I have chain.CONFIG_WEB_RESOURCE pointing to /WEB-INF/chain-config.xml. Is it possible that the MyFaces ExtensionsFilter is somehow interfering with it? If so, is there any way to remedy it? Sorry, I was focusing on the wrong problem before. It look like this getContentType() method is only available in the servlet 2.4. http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletResponse.html#getContentType() Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 11:49 AM To: user@shale.apache.org Subject: Re: Weird error for full HTML views From: Richard Eggert I'm trying to get full HTML views working. I was able to get partial HTML views (using JSP to load the HTML template) working, but I keep getting the same weird error: The full html and full xml views are different animals. If you are using a full HTML view, it must be a physical file similar to JSP. The full XML views allow you to define a config definition as the page entry point but it requires a unique suffix. The default suffix is .html and .xml but can be changed in the web.xml java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getContentType()Ljava/lang/String; at org.apache.shale.faces.ClayViewHandler.renderView(ClayViewHandler.java:385) ... The page I'm trying to load is named /htmlTest.foo and it exists only within my clay-views.xml. I've set FULLXML_CONFIG_FILES to /WEB-INF/clay-views.xml. I've set XML_TEMPLATE_SUFFIX to .foo. I have a filter-mapping for /* to point to the ShaleApplicationFilter that I set up. I have a servlet-mapping that maps *.foo to the Faces servlet. I have a mime-mapping that maps the foo extension to text/html. I have not modified javax.faces.DEFAULT_SUFFIX (i.e., I've left it as the default of .jsp), since I still have a lot of traditional JSP-based JSF pages (I did try changing it to .foo at one point, to no effect). I don't know if it's relevant, but I did notice the following lines in my log file (note the file extensions): org.apache.shale.clay.faces.ClayViewHandler:282 - Clay template restoreView for /htmlTest.jsp org.apache.shale.clay.faces.ClayViewHandler:366 - Clay template renderView for /htmlTest.jsp Does anyone have any idea of why I'm getting this error (or, more importantly, how to fix it)? JSF really only wants you to choose one type of templating. You can mix the three types but you need the shale-application library. What happens is JSF will normalize the view suffix to the javax.faces.DEFAULT_SUFFIX value. There is a preprocess command that is invoked from a filter that captures the view suffix before the normal processing of the viewId. The captured suffix overrides the default. This won't work in a portal environment and I've heard reports of it not working all the time. I covered this in more detail in a resonse to Bernhard's question [1]. The shale-clay-usecases trys to explain the problems too [2]. Unfortunately, you are better off if you choose a single JSF view entry point. [1] http://www.nabble.com/Clay-templating-tf3292202.html (should be here but I just posted the response) [2] https://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecas es/src/main/webapp/usecases.jsp?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
RE: tomahawk-1_1_?-config.xml
Ah! I figured it was something simple. Thanks! :-) By the way, as reported here (http://issues.apache.org/jira/browse/TOMAHAWK-313?rc=1page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel) there is a bug in Tomahawk 1.1.1 that causes a NullPointerException with t:jscookMenu if you don't explicitly set the itemValue property of every instance of t:navigationMenuItem. It's fixed in Tomahawk 1.1.3, but for the sake of those of us that don't have the luxury of deciding when things get upgraded on their systems, would it be possible to have value=0 added to the itemValue attribute of t:navigationMenuItem in tomahawk-1_1_1-config.xml, so that the component works by default? I'd hate for someone else to have to go through the headache I went through on Friday as I tried to figure out why jscookMenu wouldn't work for me. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 4:57 PM To: user@shale.apache.org Subject: Re: tomahawk-1_1_?-config.xml From: Richard Eggert [EMAIL PROTECTED] This is probably a dumb question, but is there some way to get Shale to load the tomahawk-1_1_1-config.xml or tomahawk-1_1_3-config.xml file that comes bundeled in shale-clay-*.jar's META-INF, short of extracting the file and putting it in my own WEB-INF or pasting the contents into my own clay-config.xml? I don't see it mentioned anywhere in the examples. There is one example but it's in the sandbox [1]. You need to add classpath*: before the resource name. This works with html templates too. !-- Clay Common Configuration Resources -- context-param param-name org.apache.shale.clay.COMMON_CONFIG_FILES /param-name param-value /WEB-INF/clay-config.xml, classpath*:META-INF/tomahawk-1_1_3-config.xml /param-value /context-param [1] http://svn.apache.org/viewvc/shale/sandbox/shale-clay-mailreader/src/main/webapp/WEB-INF/web.xml?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
Re: Stand alone tiles requirements
On 2/26/07, Joel Powers [EMAIL PROTECTED] wrote: I'm looking at SiteMesh or Stand alone tiles with a JSF application running on JVM 1.4.x (WebSphere 6.x). From here: http://struts.apache.org/struts-sandbox/tiles/index.html First off, Tiles has graduated to a Top-Level Apache Project. See http://tiles.apache.org for the latest updates. I see that tiles requires 1.4.x but in looking at the code I see it uses 1.5only features such as Generics. http://svn.apache.org/repos/asf/tiles Oh, you're looking at the TLP codebase :-) Anyway, I'm not sure what the status of 1.4 use is. When the Java 5 enhancements were added there was talk about using Retroweaver, etc. to create a 1.4-comptible version. I can't remember where that discussion went. You might want to ask on users@tiles.apache.org to find out. If you us a downloaded snapshot of Tiles you may have trouble getting things to work. Most people seem to be having success using the Tiles version downloaded with the Shale distribution. But I'm not sure if that snapshot works with JDK 1.4 or not. A 2.0.1 alpha version of Tiles is now available and should be integrated into Shale in the near future. HTH, Greg
Re: WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
On 2/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Rahul, thank you very much for your reply. After reading your statement that the dialog jars should not really effect my application, I removed them from my WEB-INF/lib directory again. Actually i had tried this before with no success, but it turned out that it was a problem with my eclispe caching stuff (even after a refresh/clean/rebuild)! So I deleted my server, created a new one, and was thrilled to see that i could go beyond what i had before..:) My happiness was short lived though.. and instead of going into the gory details, let me ask you two things: 1. Is it necessary to add this in my web.xml:listener listener listener-class org.springframework.web.context.ContextLoaderListener /listener-class /listener *even though* I don't use spring in my application? I removed it but ran into trouble and googling led me to this solution: http://www.mail-archive.com/issues@shale.apache.org/msg00050.html which made me think I ought to add in web.xml it anyways.. In any case my app would not start up without it.. Am I right..? 2. The tiles uri I used to have before (in my jsps) was http://jakarta.apache.org/tiles. However that doesn't work now and I now use http://struts.apache.org/tags-tiles. Is this correct? (I got this uri from the tld in tiles.core-2.0-r68346-SNAPSSHOT.jar). I did 1 above in order to get rid of a java.lang.IllegalStateException: No WebApplicationContext error. And I changed my uri as outlined in 2 above in order to resolve a I don't know what you mean by this uri kind of problem. snip/ About (1), if you're not using Spring, better off taking out all Spring jars and the shale-spring jar from the application. (2) sounds correct, and it might change further now that Tiles is a top level project at Apache. Again, seems unrelated to the 403 bit. -Rahul I am now back to the 403 (Access forbidden) page. Would I need to add anything more/different in chain-config.xml? Or am I again barking up the wrong tree? btw, I don't access my logon.jsp directly either. My 'welcome-file list has index0.jsp. And index0.jsp forwards to index1.jsp using jsp:forward page=index1.faces/.. This has always worked before (before I did the upgrade to the new shale/faces/tiles..) Thank you very much again for your time; I really appreciate it! Geeta snap/
[ANNOUNCE] Article: InFact Uses JSF to Power Book Search Portal
Hello, I'm pleased to announce the return of JSF Central's popular In the Trenches series. The latest installment tells the story of two developers who used JSF to develop the public-facing InFact Book Search site. Here's a quote: The first phase of the project was completed in less than three months starting from scratch. The initial feedback was very positive and was followed by requests to make some significant changes in the layout and features of the application. Our flexible, re-usable architecture for the backing bean and helper classes helped us to incorporate these changes surprisingly quickly (see Figure 2). At this point, we considered how long it would have taken us to make these same changes using the other frameworks we were familiar with, and we were glad we chose to go the JSF route. Read the full article here: http://www.jsfcentral.com/articles/trenches_6.html http://www.jsfcentral.com/articles/trenches_6.html ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com http://www.jsfcentral.com/ - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
Re: WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
fyi.. in my earlier message, I was *quoting* Craig's note.. everything
below here is what he said.. sorry I wasn't clear enough.. :)
Geeta
You will want to register your view controller beans as a managed bean
anyway, so that JSF will create them for you on demand. But, for
Shale to provide the services it does, it must know how to translate
the view id --- something like /logon.jsp -- into the name of the
corresponding managed bean. That way, when you navigate to that page,
Shale can precreate the bean and call the relevant event handlers.
Thus, the managed bean name corresponding to /logon.jsp *must* be
named logon for it to be recognized as a ViewController. In your
scenario, you left the name copied from the Use Cases example
(logon$profile), which would be suitable for a page named
/logon/profile.jsp.
[EMAIL PROTECTED] wrote on 02/27/2007 12:20:08 AM:
Rahul Akolkar [EMAIL PROTECTED] wrote on 02/26/2007 11:18:56
PM:
About (1), if you're not using Spring, better off taking out all
Spring jars and the shale-spring jar from the application. (2) sounds
correct, and it might change further now that Tiles is a top level
project at Apache. Again, seems unrelated to the 403 bit.
-Rahul
Hi Rahul,
Thanks for the reply. After a bit of trial and error I got tiles to
behave
properly. (I did remove all references to Spring btw). But for now I have
also had to remove *all* config info from my chain-config.xml; else I
can't
get rid of my 403 error. I have shelved the problem for right now so I
can
move on.
Anyway, so I at least got my app up and running. But I am having a
peculiar
problem with just one of my jsps in that I cannot seem to hit the backing
bean's prerender() or init() methods. I have tried changing the scope of
the bean to no avail.
So I went back to the usecases example to try to see if anything has
changed since the last time and saw a peculiar thing. In
faces-config.xml,
in the Validate test section, the backing bean name is validate$test
and not validator$test. According to a long ago post of Craig's:
http://mail-archives.apache.org/mod_mbox/struts-user/200508.mbox/%
[EMAIL PROTECTED]
You will want to register your view controller beans as a managed bean
anyway, so that JSF will create them for you on demand. But, for
Shale to provide the services it does, it must know how to translate
the view id --- something like /logon.jsp -- into the name of the
corresponding managed bean. That way, when you navigate to that page,
Shale can precreate the bean and call the relevant event handlers.
Thus, the managed bean name corresponding to /logon.jsp *must* be
named logon for it to be recognized as a ViewController. In your
scenario, you left the name copied from the Use Cases example
(logon$profile), which would be suitable for a page named
/logon/profile.jsp.
Has this requirement been changed in the current Shale? More importantly
are new requirements in place now? I looked through the docs for
ViewController and didnt see anything.. but I may not be looking in the
right places..
My whole problem is that my breakpoints in my backing beans in init() and
prerender() are not getting hit. My particular situation is this:
1. My faces-config.xml has this:
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-property
property-namenextAssignmentHome1/property-name
value#{worklist$nextAssignmentHome1}/value
/managed-property
/managed-bean
and my WorkListmanagerBean has private AssignmentBean1
nextAssignmentHome1;
with the appropraite getters and setters. When i step through my code, in
one of my action methods of WorkListmanagerBean I see that
nextAssignmentHome1 is not null (as it should be) and I set some values
here. At the end of my method I forward to nextAssignmentHome1.
2. faces-config also has:
managed-bean
managed-bean-name
worklist$nextAssignmentHome1
/managed-bean-name
managed-bean-class
com.intellicare.webshark.action.workflow.AssignmentBean1
/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
and navigation-rule
from-view-id*/from-view-id
navigation-case
from-outcomenextAssignmentHome1/from-outcome
to-view-id/worklist/nextAssignmentHome1.jsp/to-view-id
/navigation-case
etc.
Can you spot anything off? Because I step through the code in my worklist
bean, I set attributes for the nextAssignmentHome1 backing bean. However,
when I step through AssignmentBean1, everything I set in my worklist bean
has been reset to default (null) values! (:( I even changed the above
code
to use
