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

[larry hamel]

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.



>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?  

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.

>Job Handler:

your suggestions on Job Handling sound good to me.


>----------------------------------------------------------------------------
>Security

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.

thanks for the long-thinking :-)

larry