RE: [Modus-devs] Some general Modus comments to start with

[Nathan D. <na...@ch...>]

Hmm.  Well, I'll have to mentally chew on this a bit.  I can see the benefit
of having persistence not embedded in the contentObject, but given that I
can still store my persister as a "static" component in memory and then just
have each contentObject instance refer to it, it seems that performance at
that level should not be too big an issue.  Then we have the issue of what
is a contentObject -- is it basically just a data descriptor which is then
passed to a variety of services, or does it have a lot of functionality
built in.  I'll construct this discussion as "dumb" contentObjects vs.
"smart" contentObjects.

Perhaps we can have it both ways -- build a "dumb" contentObject
infrastructure that is used in various services, then create some wrapper
components that perform like "smart" components by encapsulating common
tasks one does with the dump contentObjects and the services.  Hmm, that
might actually be quite nice and provide a nice gradual learning curve for a
developer (starting with the "smart" layer and then being able to branch out
into their own customized use of the "dumb" contentObjects with services).
It would also, I can see, make it easier to extend Modus by layering on
services instead of having to change baseContentObject.  I guess I'm sold on
the general concept, though I want to make sure that building a simple Modus
app requires substantially less coding then building a "regular" CF app
(which is where this whole thing started).

I'll have to noodle on Jeremy's proposed API (and yes, I realize it was
meant as a proof of concept, not a finished product).  I still think we
should maintain a development style that uses methods, ie:
honda.getField("color").setValue("blue") rather than just honda.color =
"blue" -- mostly to keep things consistent and because it just feels tighter
to me for some reason.  Though, perhaps it's overly verbose.  The last big
project I managed we used Turbine (from Apache) and it allowed you to do
honda.color, but under the sheets it turned that into honda.getColor() --
that is, it was a short-hand way to access the method rather than exposed
data members.

You know, in some ways a "dumb" contentObject may be little more than its
descriptor (and perhaps nothing more than its descriptor).

Oh, and for performance I was talking about 500ms per PAGE, not per
instance, so I think we're on the same page after all.  The modusTest app
with the current build gets close to this, even on my not-so-great
workstation with lots of other stuff running.  And, most of the processing
time is in the getAllSorted(), which is atrocious (other suggestions on how
to accomplish sorting are welcomed!).

 - Nathan





> -----Original Message-----
> From: mod...@li...
> [mailto:mod...@li...]On Behalf Of Sean A
> Corfield
> Sent: Tuesday, November 05, 2002 9:31 AM
> To: mod...@li...
> Subject: Re: [Modus-devs] Some general Modus comments to start with
>
>
> On Tuesday, Nov 5, 2002, at 08:05 US/Pacific, Nathan Dintenfass wrote:
> > I've gotta run out, but just a quick note . . .
>
> I'm on BART, but just a quick note . . . :)
>
> > Yes, agreed.  The notion of the "persister" in Modus is a move towards
> > abstracting the persistence layer away from the contentObject API
> > itself
> > (though, the baseContentObject has some convenience methods that pass
> > through the persister).
>
> Excellent! I wasn't clear from our earlier conversations whether that
> was indeed a guiding principle for you or not.
>
> > Right now, each instance of the baseContentObject
> > has its own reference to a persister (which in the current "build"
> > literally
> > creates a new instance of a persister!!), and each contentObjectType
> > will
> > have will have the ability to say which persister it wants to use (any
> > persister must extend and "implement" the basePersister).
>
> Yes, that makes sense.
>
> > I do think that
> > before 1.0 we need to move away from having a separate instance of a
> > persister in each contentObject instance, but I am not sure if the
> > developer
> > should need to worry about the persister -- that is, it seems very user
> > friendly to be able to just say pressRelease.save() and have that deal
> > internally with passing this to the persister.store().  Would you
> > disagree?
>
> Well, the problem with that is that it means each content object
> instance must inherit from a class that knows how to save() and load()
> and so on. It's precisely this overhead that I'm suggesting we try to
> avoid. As Jeremy has discovered, object instantiation times are
> affected dramatically by inheritance and the # of methods.
>
> Furthermore, there's actually a problem with inheriting from a class
> that knows about persistence - in fact there are two main (design)
> problems:
> 1. it forces all your content objects to be persistable (or at least
> know about the persistence machinery)
> 2. it precludes making a content object from something that inherits
> from some other base type
>
> Let me explain those:
> 1. all content objects have save() and load() methods (because their
> base class has them) but you may want transient content objects - so it
> raises the question of what the default implementation for those
> methods is (as you say, you can have a range of persisters).
> 2. is the bigger issue. Suppose I have a vehicle component and I
> derived car and train from that. I can't easily make a persistent car
> if I need to inherit from some content object base class. This is why
> C++ has mixins and why Java has interfaces. You need a way to blend the
> implementation of one entity (car in this case) with the *interface* of
> another (content object in this case).
>
> My suggested approach - making persistence a *service* - allows you to
> side-step this. I can easily make my car object persistable by creating
> an XML descriptor for it (externally) and then binding it into the
> persistence system dynamically. Sure, it means you can't save
> honda.save() and instead you need to create a carPersister (binding in
> the car XML descriptor) and then say carPersister.save(honda) but that
> isn't really a big hardship - yet it buys a lot of flexibility AND it
> removes the per-instance overhead of the persistence mechanism
> (methods, metadata, inheritance).
>
> If CF had real interfaces, I wouldn't be as worried about this from a
> design point of view. If CF was higher-performance in its OO support, I
> might also concede this point on the grounds of simplicity. But neither
> of those are true so I'm going to stick to the idea of
> persistence-as-service (and would push for presentation-as-service too).
>
> Besides, a plugin-based architecture like that is very flexible and is
> well-enough documented in the literature that developers shouldn't find
> it too alien (note that Fusebox MX uses a plugin architecture, much to
> my surprise - and delight!).
>
> > Well, they may load faster on the server, but then the Flash movie
> > has to "load" -- the perceived time on MANY pages (including the home
> > page)
> > at macromedia.com is well over 1 second, no??
>
> Yes, in fact our target for load time is well over a second - for a
> fully-loaded, interactive page (I don't have the thresholds on hand).
> However, what we are talking about with Modus is the time it takes to
> load individual objects. A very common scenario on a website is a
> summary page that displays, say, twenty items for the user to scroll
> through. If it takes Modus 500ms to load an object and render two or
> three fields (title, date, author for example), then that page will
> take well over TEN SECONDS to load in total. I would say that we should
> be aiming for a system that can load and render a 50 item summary table
> in around 5 seconds. That's a combined load and render time of just
> 100ms per item.
>
> "I can smell your brains!"
> -- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Modus-devs mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modus-devs
>