Dave Johnson wrote:
On 6/15/06, Dave Johnson <[EMAIL PROTECTED]> wrote:
Thanks for the feedback. Lots of good suggestions there.
On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> 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
