Possibility to customize the path used by tynamo for its crud pages

This was also mentioned on the tapestry mailing list:
http://markmail.org/search/?q=list%3Aorg.apache.tapestry.users+tynamo#query:list%3Aorg.apache.tapestry.users%20tynamo+page:1+mid:vj5h6ym37gxnpiqk+state:results

Very interesting..., any ideas on how to tackle it? without UrlRewriteFilter?

No concrete idea about implementation yet - just wanted to have it in JIRA for now.
I think it is somewhat related to TYNAMO-15 as well. Maybe we can intercept calls to the defined path and handle them according to some custom logic. Guess this will require to overwrite a tapestry service or two.

Certainly there is a service which checks if there is a component available at a specific path. Our logic needs to make tapestry think our pages are at this path. We need to break out of the auto-discovering of tapestry ( .pages., .components., etc).

It would look like this:

• Symbol TYNAMO_PATH configured to admin

IF no /admin/Add page defined THEN
USE tynamo-lib:/pages/default/Add

Ok, I tried it the hard way: override ComponentClassResolver. But this gives me errors and we would need to rely on internal tapestry classes. After all, this seems a bad idea.

What speaks against the UrlRewrite facility of tapestry? I've just tested it and it looks very promising.

It would look like this:

• we put our default pages under the "tynamo" LibraryMapping defined by tapestry-model-core
• normally, they are reachable with <appcontext>/tynamo/Add, etc.

• we contribute an UrlRewriter:

IF
request is to a crud page (<TynamoSymbols.TYNAMO_ROOT>/AddPage)
THEN
IF NOT
page is available at <TynamoSymbols.TYNAMO_ROOT>/AddPage
THEN
rewrite to /tynamo/Add

This would allow the user to
a) specify at which path tynamo should handle requests (with a configuration symbol)
b) allow to override our default implementations only if needed

Only drawback I see:

• if the developer wants to link to one of our provided crud page, he needs to link to "tynamo/AddPage" instead of "/AddPage".
  But the end user would never see this.

Didn't monitor this issue closely until now. Yes, I had thought of the same and I reached the exact same conclusion as you did, rewriting the url is the best option. It'd also be beneficial for url-based security rules (allow /admin/* for role ADMIN). I agree that the default page location (or names) need to change, otherwise they'll collide too easily with possibly existing application pages. Is "tynamo" the right name for TYNAMO_ROOT that I'm not sure of. If we ever needed to change our name it'd make a lot of grief and we don't have to toot our our horn everywhere. /crud/ would be very descriptive but it sounds rough. /model/ is too generic for this purpose. /admin/ would be a good default but if we provide a contribution anyway (rather than instructions only) it would defeat the purpose. Convention-over-configuration rule speaks for /admin/ though. /cms/ - hate the abbreviations. Maybe /contentmanagement/, it's probably unlikely to collide with existing paths. What do you think, any other suggestions?

What speaks against the UrlRewrite facility of tapestry? I've just tested it and it looks very promising.

Nothing at all, I was just asking if there is a better option.

I agree that the default page location (or names) need to change, otherwise they'll collide too easily with possibly existing application pages. Is "tynamo" the right name for TYNAMO_ROOT that I'm not sure of.

"tynamo" would be used by developers only. In my naming TYNAMO_ROOT is the path where the crud pages are visible to the web users. It should be configured by the developer and default to "/".

But the actual default pages need to reside in some location.. imho it needs to be something that:

• does not collide with the developer's pages.
• is short enough to not read ugly in the code

If we ever needed to change our name it'd make a lot of grief and we don't have to toot our our horn everywhere.

Agreed.
But to be honest, I can't think of something that does not use our name.

/crud/ would be very descriptive but it sounds rough. /model/ is too generic for this purpose. /admin/ would be a good default but if we provide a contribution anyway (rather than instructions only) it would defeat the purpose. Convention-over-configuration rule speaks for /admin/ though. /cms/ - hate the abbreviations. Maybe /contentmanagement/, it's probably unlikely to collide with existing paths. What do you think, any other suggestions?

These seem to be proposals for TYNAMO_ROOT defaults, aren't they?
Because this could be made configurable by the user, we don't need to decide on this now.

But we need to decide on where the default pages reside inside our tapestry-core package. My proposal mentioned "tynamo" only because there already is a "tynamo" library mapping in place. My oppinion is that we should try to keep the namespace as clean as possible.

Although you can easily customize the URLs for the Tynamo pages using the new tapestry-routing module I still want to be able to move the pages location inside the project as I want. For instance move the pages out of the root into a subpackage.

I'm working on it.

Added new service called TynamoPageRenderLinkSource that holds "pointers" to the the default tynamo pages.