On Wed, Jan 28, 2009 at 6:45 PM, Dave Newton <newton.d...@yahoo.com> wrote: > The action doesn't need to know; that's the point. The framework serializes > the action based on the content type handler (CTH) registered to the URL > extension. > > For example, the json extension uses a JSON serializer which will serialize > the entire action, or if it implemented ModelDriven just the model. The > action code doesn't care that it will be serialized as JSON, it just goes > about its business. > > In your case you'd construct the SyndFeed object in the content type > handler. Actions are intended to create known data to hand off to the view > layer--you shouldn't need to convert *any* old objects to your desired > output, you just need to convert the object(s) your action > creates/retrieves/etc.
I understand the general idea, but I guess where the problem lies for me is that RSS/Atom isn't intended for generic object serialization, but rather constructed very much around content with a title, description, URL, etc. To me, this implies that there needs to be code to map whatever the particular model is to the needs of the RSS feed. Your suggested approach would lead, I think, to either multiple content handlers (each understanding how to construct a feed from a particular model) or an interface approach where it's understood that the Model will implement a particular Feed interface so that a generic CTH can create a feed from different models. The interface approach makes the most sense to me, but I think there are still issues around doing this generically (for example, in my particular usage scenario, it's not reasonable that the model objects know what URL they can be addressed at). Thanks for the input - I'm mostly really loving working with the new rest/convention plugins, but there's stuff in the corners I'm still wrapping my head around. Bill -- Bill Stilwell - http://www.marginalia.org/ bill.stilw...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
