you mean to have different views, for instance :
view #1 contains : forums, html block 1, html block 2
view #2 contains : news, html block 3
and the url could be something like : index.html?view=1
there's the contextual html block already, but contrary to making the visibility dependant on the directory of the html-module only, we could put a interceptor in the control flow that would not only change the visibility, but the position of a module as well. And that dependant on such a view parameter.
A question going further would be, can a logged in user customize the view (collapse or even change visibility/position of blocks). But that is not a prerequisite for the shop.
...but the position of a module as well.
the position of a block, I mean.
This is something I want to change in Nukes 2. Yes it is design around the concept of reified invocation (to use marc's favourite expression :-) ) and the view should be constructed by an Interceptor and put in the Invocation object by it so the dispatch Interceptor uses it. It allows to swap implementation easily.
Now for the concrete thing, there are several ways to do that, the way it is done today in Nukes 1.x is :
target = get the target module (or default if no specified) get all the blocks filters the blocks that should not be rendered compute everything
that's a bit primitive and does not give much flexibility for some site designs. I don't want to spend a lot of time on that for Nukes 2.0 alpha/beta releases so it mayby still the same view or something simple with a set of Pages that aggregate components. But the design will allow to change it later easily.
Where would you put that in (in 1.1)?
Are the blocks render() methods called before the module's operation then it wouldn't be a good idea to do it there as it would waste cpu ressources to render first and dispose then. On top of that it would prohibit the addition of blocks.
What is the state of 2.0? Does it make sense to target 2.0 for my work? Currently I'm using the cvs head (ok, about 7 days old).
I'd be interested in helping to code the views.
To implement the views, would the strategy beto stop and start (as MBean-Server invocation) the blocks
or to intercept the render method for nonvisible blocks but keep them running.
I think the best would be to intercept before dispatching and remove the block not needed.
I still try to get my head around how it best would be done. Block's process() methods are called from the org.jboss.nukes.core.Main class. Would you suggest to continue calling the process() methods and just omit the output in an interceptor, or would you think to hook in at this point and omit even the call to process?