Okay, you all just got saved from a long winded email, as Outlook just
crashed as I was nearing completion. So I will try to say it again in a
much shorter way.
>
> <a
>
href="$Dynamicuri.setScreen("GetWMPageScreen").addPathInfo("page","apage.wm"
).toString()">...
>
This can lead to problems with url hacking. Most of the time the hacker
would just get crap, so maybe it is not a big issue. But it could lead to
security problems; for example, if a check is being performed in the Screen
on permissions and the template is assuming this security check was
performed. Also a hacked link might get into circulation, somehow, which
makes a potential user think they are seeing the application they expect,
but nothing is working properly, so they leave with a bad impression.
I have used two ways to avoid this.
1. In an application where you are going to have a Screen per template, it
is better to have the screen set its template.
2. In some cases you may be using Turbine for its content modularization,
security, session management, etc., while still having many pages which do
not necessarily need their own Screen. In this case it would be nice if a
template could set its Screen, so it is not in the url. In the FreeMarker
stuff within Turbine, I set up a folder analogy for templates, so that
templates are assigned a Screen based on where they are located in the
directory tree. I thought this was something a designer could grasp with
ease, since they would then be largely ignorant of how screens were being
assigned and the could add a page to the site which was "static", without
any Java code needing to be written. They would then link to the page with
a faily compact syntax: <a href="${link("/path/to/template.html")}">click
here</a>.
An alternative to (2) would be to set up a service type object that is keyed
from a pathinfo parameter and then it returns the path to the template, the
associated screen, etc. I originally rejected this idea in favor of the
above folder analogy. But I can't seem to remember any really good reason
against it. It strikes me a bit as a "God" object, but maybe not everyone
will agree. Frank and I were just discussing this same sort of idea, but he
was thinking of using xml to spell out the relationships, and I was
originally thinking database when I rejected it. It does seem better as an
xml solution. This solution also has the small advantage of a better
looking url as it is ugly to pass the path to the template within Turbine's
use of the pathinfo.
Well this is getting long again, so I'll wait and see if anyone comments.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
