Re: This Shale/Tiles configuration works
Hi, I am interested to discuss new features to a future version of Shale and I would like to know if there is interest on discussing them; if so, please reply. Meanwhile, I am writing down the details. Un abrazo, Vladimir. PS: Sorry for my english :( --- Dick Starr [EMAIL PROTECTED] wrote: I have been trying to get my Tiles app working with the current Shale release (thanks Craig and Greg for your help), and am currently working with the shale-framework-20061116 jars. My running version used only the shale-framework-20061004 jars. I have discovered that I can use the 20061116 shale-tiles and tiles-core with the 20061004 Shale release, and have successfully implemented the Tiles 2 FAQ changes. Once I replace my 20061004 shale-xxx jars (except for the two newer Tiles jars) with the 20061116 jars my app fails like before with this log data: INFO: Undeploying context [/starraShale] log4j:WARN No appenders could be found for logger (org.apache.commons.digester.Digester.sax). log4j:WARN Please initialize the log4j system properly. Nov 17, 2006 10:14:26 AM org.apache.tiles.listener.TilesListener contextInitialized INFO: Initializing TilesListener Nov 17, 2006 10:14:26 AM org.apache.tiles.listener.TilesListener readFactoryConfig INFO: CONFIG FILES DEFINED IN WEB.XML Nov 17, 2006 10:14:26 AM org.apache.tiles.listener.TilesListener initDefinitionsFactory INFO: initializing definitions factory... SaInitializer.contextInitialized Nov 17, 2006 10:14:26 AM org.apache.catalina.core.StandardContext start SEVERE: Error filterStart Nov 17, 2006 10:14:26 AM org.apache.catalina.core.StandardContext start SEVERE: Context [/starraShale] startup failed due to previous errors My log4j is as follows: log4j.debug=true log4j.appender.C1=org.apache.log4j.ConsoleAppender log4j.appender.C1.Threshold=DEBUG log4j.appender.C1.layout=org.apache.log4j.PatternLayout log4j.appender.C1.layout.ConversionPattern=%d - %p %c - %m%n log4j.rootLogger=DEBUG, C1# test log4j.logger.com.ibatis=DEBUG, C1 log4j.logger.java.sql=DEBUG, C1 log4j.logger.org.apache.commons.digester.Digester.sax=DEBUG, C1 log4j.logger.org.apache.shale=DEBUG, C1 log4j.logger.org.apache.catalina.core=DEBUG, C1 log4j.logger.org.apache.jasper.compiler=DEBUG, C1 log4j.logger.com.starrcs=TRACE, C1 As a test I reduced my shale lib jars to shale-core, shale-tiles, and tiles-core. This configuration works with the 20061004 jars (i.e. deploys and displays my first view) but fails with the corresponding three 20061116 jars. I realize that I may need more shale jars with the later release as the work seems to be distributed differently within the jars, but I was wanting to make the test as simple as possible (note from above that it also fails with the full set of 20061116 shale jars). Bottom line seems to be that you can get away with using the latest shale-tiles and tiles-core with an earlier release of Shale. I never like mixing releases, but it is working for me - and I want to test the latest Tiles. If anyone has the latest Shale/Tiles working please post what Shale/Tiles version you are using, and I will try it. Thanks, Dick Sponsored Link Mortgage rates near 39yr lows. $420k for $1,399/mo. Calculate new payment! www.LowerMyBills.com/lre
Re: This Shale/Tiles configuration works
On 11/18/06, Alarcón Vladimir [EMAIL PROTECTED] wrote: Hi, I am interested to discuss new features to a future version of Shale and I would like to know if there is interest on discussing them; if so, please reply. Sure! The best way would be to start a new thread on the mailing list and use a descriptive subject line. (Here, you've replied to an unrelated thread about Tiles.) And your English is fine. :) -- Wendy
Feature 1: Navigate-In Navigate-Out for each page.
Feature 1: Navigate-In Navigate-Out for each page. I understand that Shale uses a bean for each page, that's called backing bean. A lot of times I have found that I need some code to set-up and for tear-down the page. Typically for loading values from DB in the form of the page, setting session variables or removing these session variables when exiting the page. So, what do you think of having a couple of optional methods named navigateIn() and navigateOut() in each backing bean that are called by Shale every time that the application enter or exit each page? For example, if I am in page A and I press a command that decides to go to page B, Shale would execute navigateOut() on page A and then navigateIn() on page B. On the contrary, if the command decides to stay in the page A, Shale doesn't execute any of them. I know that Shale already uses init() and destroy() but I think these methods do not address very well the problems mentioned above. Another though: It's not uncommon that the navigateIn() method can go bad. For example if it tries to fill in the form, retrieving from the DB the details of customer that doesn't exist anymore. It would be good to have a simple way to redirect the processing returning some value (or throwing an exception) that represents the new page that I would like to go, if that happens. That's it. Any comments? Vladimir. --- Wendy Smoak [EMAIL PROTECTED] wrote: On 11/18/06, Alarcón Vladimir [EMAIL PROTECTED] wrote: Hi, I am interested to discuss new features to a future version of Shale and I would like to know if there is interest on discussing them; if so, please reply. Sure! The best way would be to start a new thread on the mailing list and use a descriptive subject line. (Here, you've replied to an unrelated thread about Tiles.) And your English is fine. :) -- Wendy Sponsored Link $420k for $1,399/mo. Think You Pay Too Much For Your Mortgage? Find Out! www.LowerMyBills.com/lre
Re: Feature 1: Navigate-In Navigate-Out for each page
On 11/18/06, Alarcón Vladimir [EMAIL PROTECTED] wrote: Feature 1: Navigate-In Navigate-Out for each page. I understand that Shale uses a bean for each page, that's called backing bean. A lot of times I have found that I need some code to set-up and for tear-down the page. Typically for loading values from DB in the form of the page, setting session variables or removing these session variables when exiting the page. So, what do you think of having a couple of optional methods named navigateIn() and navigateOut() in each backing bean that are called by Shale every time that the application enter or exit each page? I think the use cases you describe are adequately addressed with the current APIs ... see below for more. For example, if I am in page A and I press a command that decides to go to page B, Shale would execute navigateOut() on page A and then navigateIn() on page B. On the contrary, if the command decides to stay in the page A, Shale doesn't execute any of them. I know that Shale already uses init() and destroy() but I think these methods do not address very well the problems mentioned above. Another though: It's not uncommon that the navigateIn() method can go bad. For example if it tries to fill in the form, retrieving from the DB the details of customer that doesn't exist anymore. It would be good to have a simple way to redirect the processing returning some value (or throwing an exception) that represents the new page that I would like to go, if that happens. That's it. Any comments? For setup actions, I'd suggest using ViewController.prerender(). It is called *only* on the backing bean whose view is actually going to be rendered, so it covers both the case where you navigate elsewhere (prerender gets called on *that* view's bean) or if you stay here (prerender will be called on your own page bean). Given that, I think your navigateOut requirements are covered by destroy() ... destroy() will get called on both beans if you did navigate, but you won't have set anything up on the from bean. Note also that destroy() is called *after* rendering is complete, so you can clean up resources that you needed for rendering. Vladimir. Craig --- Wendy Smoak [EMAIL PROTECTED] wrote: On 11/18/06, Alarcón Vladimir [EMAIL PROTECTED] wrote: Hi, I am interested to discuss new features to a future version of Shale and I would like to know if there is interest on discussing them; if so, please reply. Sure! The best way would be to start a new thread on the mailing list and use a descriptive subject line. (Here, you've replied to an unrelated thread about Tiles.) And your English is fine. :) -- Wendy Sponsored Link $420k for $1,399/mo. Think You Pay Too Much For Your Mortgage? Find Out! www.LowerMyBills.com/lre
