Hi Shash.

Thanks for the info.

I am hoping Santanu and Philip weigh in here as well, as they have done most of the 
work on the 1.0 branch, and it is their work that I want to merge into the 2.0 branch.

As far as ModelAction is concerned, happily that is a clnt-struts object, so this is a 
good place to put struts specific stuff.  The only Keel specific object that there is 
a conflict with is NestedException. And that is an object that I am wondering if we 
can get rid of.

As for svc-struts-fileupload, it would be nice to find out if this can be made more 
generic, as the application I am working will eventually have to support multiple 
clients.

Regards,
Steve

--
Java/J2EE Developer/Integrator
Currently "On the Road"
214-724-7741

----- Original Message -----
From: Sasvata (Shash) Chatterjee
Sent: 9/11/2003 2:04:28 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Keelgroup] Merge 1.0 -> HEAD : First Pass is done

> Steve,
> 
> I can't devote much time to this at the moment, but I can help you out 
> with some idea of the refactorings that went into this side of Keel in 
> 2.0.  You'll find the content of the 1.0 ModelAction has been broken up 
> into three pieces.
> The common part of what any Keel client would need to do, including 
> encapsulation of the JMS connectivity,  has been abstracted  to 
> org.keel.clients.AbstractKeelClientConnector (in keel-server).  The next 
> piece up the chain is the common piece that all webapps (Struts, 
> Velocity, Cocoon, but not CLI) need to do, particularly convert 
> HttpRequest/Response to KeelRequest/Response: and that is in 
> org.keel.clients.webapp.AbstractWebappClientConnector (in keel-server).  
> Next, the common part that *all* Struts actions would need to do is in 
> org.keel.clients.struts.StrutsClientConnector. Finally,  ModelAction 
> becomes just the default action (you can see how little code it has), 
> but any action can use the same code to access Keel as necessary.
> 
> I don't think Eclipse's or any other merge tool will help here, it needs 
> to be done manually with a lot of thought and care. The current 
> ModelAction as you checked in doesn't seem the right thing to do. To 
> merge the functionality from Santanu's changes to 1.0 ModelAction into 
> 2.0, I'd recommend diff'ing the 1.0.1 tagged ModelAction.java to 
> Santanu's version to identify what actually changed.  You should be able 
> to find similarities with the original ModelAction in the three pieces 
> of code I mentioned above, and then make similar changes from the diff 
> in each piece as appropriate.
> 
> I have a couple of concerns that I would like to bring up.  I think the 
> Struts-specific parameters and functionality should stay only in 
> clnt-struts.  The org.keel.clients.webapp package should contain generic 
> code that is applicable equally to Struts, Cocoon, Velocity, etc...i.e. 
> all web clients.  So, if translation from Struts to a generic parameter 
> passing scheme needs to happen, the place to do it is 
> StrutsClientConnector.  The next is more something Santanu can address. 
> I haven't looked at it yet, but svc-struts-fileupload sounds like it is 
> Struts-specific, but if you write a model using it, you can't use Cocoon 
> any more for your app.  Are we breaking the "Any Service, Any 
> Deployment" part of our motto?  Can this be made generic?  Or maybe it 
> is not a generic Keel-server-side service, but part of the keel-client 
> functionality that needs to be moved over to clnt-struts?
> 
> Shash
> 
> 
[snip to save bandwidth]


http://keelframework.org/documentation
Keelgroup mailing list
[EMAIL PROTECTED]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com

Reply via email to