With the emergent of new technologies JSF, STRUTS ACTION2, SHALE and VELOCITY or even PHP as in NING.com example, how do we keep everyone happy with a view that is independent? The concept of shale seems to address this issue. If Roller can be written independent of view technology (since most are embracing the ease of use UI technology from JSF) and the advantages offered by POJO making note of JPA and EJB 3.0 we can all achieve harmony. Roller can come with a default setting as it is in present state but also easily adaptable to other states regardless of underlying data persistent mechanism and also its view presentation state.
Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > On 6/15/06, Dave Johnson wrote: >> Thanks for the feedback. Lots of good suggestions there. >> >> On 6/14/06, Allen Gilliland wrote: >> > I think this looks good and will be a give improvement over what we >> > currently have. Here's a few notes/comments ... >> > >> > 6. You have a section called "Changes to existing POJOs" where you list >> > new methods to be added. This is the part I disagree with the most so >> > far. I don't think those methods should be added to our existing POJOs >> > because they are not related to the domain model in any way, they are >> > only related to the way we render our UI. I would much prefer to see >> > these methods be added to a class which extends the current pojos. >> This >> > also has the benefit that we don't need new methods for some things >> like >> > getTransformedText(), instead I think we should just override the >> > default pojos getText() method to return the transformed text. >> >> Yes. I like the idea of extending the POJOs. I'll update the proposal. > > On second thought, I'm not sure about this one. > > First, the new methods are related to our domain model. No matter what > your context is, if you are calling the Roller interfaces and dealing > with POJOs you're going to want to do things like getTransformedText() > to get the plugin processed version of the entry. Transforming text is > not part of the editor UI or the renderer UI, it's an operation that > the entry should provide. For example, if you're writing a command > line utility that calls the Roller interfaces to perform a system > backup or weblog export, you'd need that method. I would argue that a cmdline tool is a UI, but yes, I see your point. Some of those methods may be part of the domain model and in those cases it's obviously okay if the methods go directly into the pojos. I think we should have a little bit of discussion about which methods those are though, so that we don't end up mixing rendering and business logic. > > Second, how do we go from a list of WeblogEntryData objects returned > by the backend to a list of wrapped WeblogEntryDataEx objects? Do we > do a copyFrom operation for each object? Do we extend the wrapper > instead? Or do we just map the extended WeblogEntryDataEx object via > Hibernate and persist it instead? Those aren't really appealing > options. I am definitely not suggesting that Hibernate be involved in this. The extended version of the object should never even be conceived of outside of the UI layer. That being said, maybe extending pojos isn't the best way to have described this. I would say that using a wrapper is the better solution, or in this case we would extend our auto generated wrappers. I am not particularly crazy about extending auto generated classes, but that's part of the reason why I originally suggested that we maintain the wrappers manually. My opinion is that in the rendering system we should attempt to just used the wrapped versions of the pojos for everything. There is no reason why templates need access to non-relevant business methods during rendering. Hiding those methods and data seems like a good idea to me. > > I don't like mixing UI into the POJOs either and I don't want to > introduce any dependency on Servlet API or Struts or Velocity, but > there are cases where POJOs need to know URLs and cases POJOs should > be expected do rendering-related things (i.e. getTransformedText()). Agreed, but I still want to make sure we are making thoughtful decisions here. Mixing UI and business logic is definitely a bad thing, so we want to tread carefully here. I think one of the other technical limitations that prevented us from processing more urls in the pojos in the past is that we had this expectation that only the presentation layer can know what the app context was and it's root url, but if we overcome that problem then we can rethink that a little bit. I know that you created that absContextUrl param in the RollerConfig and are setting it dynamically now, but I think that may not be the best approach. I think it's better if we force users to set the site's absolute url as part of the install process, once that is done then constructing all the urls in the system is trivial. I believe most other blog software does this and I don't think it's a big deal. This is the approach I would vote for. -- Allen > > - Dave Ransford Segu-Baffoe [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.noqturnalmediasystems.com/ http://www.noqturnalmediasystems.com/Serenade/ https://serenade.dev.java.net/ --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
