Thanx, Graig, but you opened more new questions as you answered :-) On 10/4/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: ... > > > > I would think that for most web applications, you wouldn't want a user > to > > > attempt to jump into the middle of a dynamic web application without a > > > context within the flow of the application? > > > > You mean, coming in with a non-functional link with some parameters? > > That's not a problem, you can detect it pretty early in the base > > action (filter whatever). The problem is, that if all your links are > > posts, you will be considered as not-interesting content by the search > > engine (only one url, different context). In a B2C business it's a > > kind of death... > > As others have said, that particular issue is inherited from Shale's > dependence on JSF. If you don't like POST-only webapps, you'll want to look > elsewhere. On the other hand, being worried about whether a search engine > will index pages of a dynamic web application (as oppposed to a primarily > static web application that might have some dynamic aspects) seems like a > contradictory set of motivations :-). In particular, you will most likely > not like *any* Java based web application framework based on using > RequestDispatcher.forward() -- including Struts, for example, because the > URL that the client thinks it is indexing is *not* the URL of the action > that actually produced the content of that page.
What about a CMS, a Catalogue, a Shop? You have dynamically edited and produced pages, which aren't changed on the fly, but maybe once in month, which you explicitely wish to become indexed? Do I get it right, that JSF isn't ment to be used for large RL applications? Ok, it may be possible to create a FrontController infront of a JSF application, which could accept get urls and transform them into "what jsf expects", can I also plug behind the JSF app and transform the outgoing urls? Btw, struts is perfectly crawlable, since you have a different url for each page. This will not let you index a concrete page, but the whole site will be at list indexed. In opposite, a JSF site will return different content to the "same url", at least from crawlers point of view. This will throw your complete site out of the indexer, as the crawler would think that you are "cloacking". You might or might not like this crawler logic, but at least yahoo, google and msn are following it, and there are about 90% of the market (at least here, in germany) so you can't ignore them. > > There is a Wiki page: > > http://wiki.apache.org/struts/StrutsShale Thanx, I searched apache wiki for pages with "Shale" in title and in full text, but it didn't returned any results :-( > > > > > > You might pick up one of the many books published on JSF. My favorite > is > > > coauthored by one of the Struts committers (David Geary - Core > JavaServer > > > Faces, ISBN 0-13-146305-5). > > > > Hmm yes, but isn't David a RoR convert now? > > He definitely likes RoR, but he's also a Struts committer that has > contributed significantly to Shale :-). In particular, he's been > particularly active in the integration with Commons Validator and with > Tiles. That's another interesting question, if JSF is all-component, what do I need tiles for? I mean Tiles was cool to define a common renderer for an abstract view-component which was then implicitely defined with struts-classic. Now JSF supports component-rendering which should make Tiles obsolete. What would I need Tiles for then? Or do I miss something (as usual)? :-) thanx for your time regards Leon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
