[Opensource] Future Code for Expresso 5.1 and beyond [LONG THINK TANK ARTICLE]

[Michael Rimov]

At 12:29 AM 11/3/2002 -0800, you wrote:
>hi Mike,
>
>+1 for xml configs of pieces.
>
> >        <message-bundles>
> > 
> <message-bundle>/com/jcorporate/expresso/core/Messages.properties</message-bundle> 
>
> >        </message-bundles>
>
>nit-pick: consider tag names that differ by more than 1 char.

Sure, which would you want better.  Something like:

         <message-bundle-list>
                 <message-bundle/>
         </message-bundle-list>

??





> >Pseudocode:
> >
> >        DBObject.getField().asString()/.asDate()/.asInteger()  etc.
> >
> >                or
> >        (Date)DBObject.getField()/(String)DBObject.getField() etc.
> >                or
> >
> >        DBObject.getFieldString()/.getFieldInt()/.getFieldDecimal()
> >
> >Maybe it's preference, but I don't really like the 3rd method, even 
> though that's what we're doing right now.  The biggest problem is that it 
> is part of the reason we have this monster of a DBObject class right 
> now.  By delegating conversion code to the field object (as in #1) we 
> slim down DBObject.   #2 is easier to code in that you make DBObject a 
> dynabean and leave it up to the coder to know what is what.... but I 
> think it might lead to weird class cast exceptions.  So I'm currently 
> leaning towards #1 as my own personal preference.
>
>does choice 2 work if we want transformations from one type to 
>another?  it is useful to have every field rendered as a string sometimes. 
>(everything coming from SQL is a string under the hood, so this should 
>remain inexpensive, right?)
>
>if choice 1, in essence, just moves the methods from DBObject to DBField, 
>are we creating a monster DBField class?

Actually, it doesn't create a monster class.  I should clarify in that 
DBField is actually a metadata class.  Check out:

         com.jcorporate.expresso.core.dataobjects.DefaultDataField

It's pretty manageable.

Choice 2 does not allow for transformation between data types.


>unless I'm missing something, +1 vote for choice 3. (i.e. leaving methods 
>in DBObject).  these methods get a lot of use in expresso, so convenience 
>(smaller # of keystrokes) may deserve more weighting.

And that's certainly a possibility.  I'll keep it in mind.

<snip> <snip>


>your security plan sounds good, but consider setting as priority #1 the 
>removal of the password out of the cookie AND the session.  yes, it is an 
>encryped password in cookie, but that doesn't make our security story 
>sound good; and caching the password in the session is just awful.  it 
>defeats the purpose of keeping a one-way hash in the database.  it was 
>useful for someone recently, but that should be an option at best; 
>frameworks should have decent security stories out of the box, which can 
>be made weaker if necessary.

I'll answer this paragraph in a day or two after I get all my thoughts 
together on it :).  Obviously, I was absent from the list for the first 
discussion :)

                                                 -Mike