struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Mills <duncan.mi...@oracle.com>
Subject Re-use and State in Shale
Date Tue, 18 Jan 2005 00:44:10 GMT
After some brief exchanges  with Craig on Shale it seemed sensible to 
move discussions onto the dev list for wider input.
At the moment I'm trying to envision how the Dialog features of Shale 
are really going to work to provide the proposed features in the initial 
Shale Wiki document.  I think the major issues that I have right now 
with the direction that the implemented code is going revolve around this.

1) I think that it might be a good idea to rename "dialog" to something 
else whilst it's still early days - although dialog is descriptive of 
this scope in many ways, it also has UI connotations which may be 
misleading.  "Process" is probably a better generalisation for the scope?

2) How is the dialog/process scope defined?  Craig has proposed the 
simple solution of using directory boundaries to define this.  Although 
I can appreciate the elegance of this, it pretty much clobbers any page 
reuse model  within Shale.  Now it may be that this is not important to 
everyone - if you assemble pages from Tiles or something similar you can 
argue that page re-use is not important as long as region / fragment 
re-use is possible. But it's pretty important for us (Oracle).
I think that generally process (dialog) scope should be more than just a 
bucket.  If I have to manually manage the teardown of such a scope then 
I'm not gaining too much in using a framework.  On the other hand, if I 
want the framework to manage the state scope for me automatically then 
that framework will have to be richer in terms of metadata to manage 
inter-scope state mapping on entry and exit, plus plug points for 
programmatic interaction

3) Faces navigation metadata is not enough.  If you take the view that 
processes (dialogs) are re-usable components, as the Shale specification 
does, then that implies that they should be pluggable into a faces 
navigation case.  If you don't do this, then you've not really got a 
component model as the navigation will depend on the components 
implementation details

Any Thoughts / Feedback on this?

Duncan Mills
Oracle Corp.
 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message