Struts User wrote:
Backing beans and tiles need to co-exist in any decent dynamic web or portlet application. This is a very powerful presentation framework.Having said all this, the framework is powerful for sophisticated web
production side, where all fragments of each page are completely dynamic
based on built-in backend intelligence. Tiles is appropriate for such
page, rather than each page need a backing bean.
Hi Batien,
I am running the struts-shale-mailreader and just started to look into Java Server Faces and Shale. Thus, I am not totally familiar with the new frameworks and hope you can bear with me.
Are you saying that Tile and backing bean don't have to co-exist? I thought Tiles and backing bean are two different things. Backing bean is sort of like ActionForm in Struts. More accurately, backing bean is like OzPage in Tak's introductory document.
Backing bean is a power tool under jsf. In a typical dynamic page, there is NOT a 1-to-1 mapping between a backing bean and a navigated page. A page is made of many dynamic fragments, each fragment has its own backing bean to receive data input from user and to push relevant data back to the user depending on user request context. Jsf provides this required infrastructure and fully configurable under managed beans. For example, if user asks any information related to company X in your portal directory, the portal supply requested information together with user existing authorized services under a complete layout of company X name brand (with company X logo vision, product vision, and copyright, etc) by just changing the contents of the company backing bean. The components and layouts to make up a page are re-useable.
Tiles enables you to encapsulate the layouts and insert dynamic fragments to the page. For example, your portal enables user with different portal tabs so user can organize his/her authorized services in relevant portal tab, named by the user in his/her own language. Each portal tab has differnet layout designed for its purpose. The design of your portlet authorized services may follow a typical portlet layout with a portlet header for current status of PortletMode and portlet WindowState, followed by portlet contents. Hence, in each portal tab page, you have a tab layout and the portlet layout as raw templates. You insert relevant contents to the raw components having their own backing beans in the raw templates. Tiles is a very clean and powerful for this job.
Under Shale, Tiles can be a plug in, similar to current tiles under struts. The design can be similar to what has been done under MyFaces for tiles. Each nagigated page is routed to a tiles definition with its own layout. Any attribute in a definition can be a page fragment or another definition. This enables you to be simple at the beginning and further drill down for more dynamic content implementation. I hope someone has time to port Tiles under Shale so it can be used under any compliant JSF implementation. If i have time i will do it. But life will not always go according to your wishes.
Currently, i use MyFaces + Tiles + Spring IoC. I will use Shale as a framework for application filter to leverage on whatever developed under Shale, while inserting whatever servlet filters you already have for your current applications using common-chain in Shale.
BaTien DBGROUPS
Please correct me if I am wrong.
Thanks! Lee
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
