jon * wrote:
>
>
> I can imagine a case where some WM screens don't have any dynamic content on
> them except for the links. So, having a .java file for each of the WM
> screens would be a real pain in the rear. I would like to case for that.
>
> When I think about MVC, I think about building the logic for the page
> outside of the page (ie: in Java). I don't think about also having to build
> all the links in the java code!
But if the links you mention above are dynamic, won't their values most
likely be driven by some kinda logic that should be handled in a screen.
For example:
if ( something )
{
//use these URIs and this information
}
else
{
//use these URIs
}
But, I do kinda see what your saying. So I think the decision boils down to
whether
we add more complexity to the page author or leave it to the programmer who
is probably already smart on DynamicURIs.
I'm just trying to keep the WM script a no-brainer for page authors. I'm sure
we could customize (add tags) to WebMacro to do the things you are talking
about.
If we do decide to add tags to handle such things as :
$dynamic.setScreen("edit.wm").addPathInfo("jobid", $job.getId() )
Then I think WebMacro becomes more then just a Service in Turbine (it becomes
bound to Turbine) and we should look at how to make a customized
version of it that's optimized for use in Turbine (that may not be such a bad
thing).
--
Dave
[EMAIL PROTECTED]
your flame > /dev/null
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
