[Seaside] Re: Getting my project started from the ground up.. (using Seaside, Glorp, Mewa?)

[Rick Flower]

Yanni Chiu wrote:
> - Don't start with user login. I've stabbed at it about three times
> and I'm still not satisfied with the result. Currently, I use the
> Postgres username/password, not a separate table. So just hard code
> a user for now.
I think with what I've already got going with Glorp, I can do easy lookups
for users in the database, so I guess I'm not convinced of the merits of
backing out (or bypassing) that code yet, but I will keep that in mind if I
find myself spinning in circles
> - Skip Glorp and Mewa for now. Just write SQL directly, and walk
> the result sets to either create object instances or pump out HTML.
> In the case of simple reports (i.e. no post-query processing needed),
> mapping the SQL result to HTML would be far easier to understand
> than mapping the SQL result to objects (via Glorp), then adding
> MEWA descriptors to use the MEWA table display.
Ok.. Point taken -- I guess I can see where figuring out how to plug all
of this stuff together might be a bit overwhelming for a Smalltalk newbie
like myself.
> - When you get to online ordering, you might start thinking about
> Glorp and MEWA. But you might find that what you have works just fine.
Yeah, this is one of the harder areas to deal with which requires a bit more
careful thought than other areas of the application.. In my case, I 
think I can
steer away from a shopping cart model that so many web-apps use.. I really
only need a single page with a big table of items that people can update
quantities for and hit a button at the bottom of the page.. However, 
handling
Paypal transactions is another story and I'll likely need to write code from
scratch for that (and is a bit OT for this discussion)..
> - To handle update of contact info, just create a contact object
> corresponding to the form you want to show. Generate an UPDATE SQL stmt
> from that contact object (the form processing should stuff the values
> for you). Again, you might consider adding MEWA (and maybe Glorp)
> at this point as well.
Could this not be a method of a "User" object -- perhaps one method to 
generate
the update HTML and another one to update the database object?  I guess
you've somewhat got my OO brain in gear now.. Any other options/opinions?
> You mentioned VW, are you using the NC (non-commercial) version?
> It sounds like your app. is commercial use. What is your timeline,
> do you have to have your app ported by a certain date? What is the
> range of functionality, is there more than what you've described?
Yes, I'm using the NC version for now which I gather is fine after I 
spoke with
one of their license people -- it's really only as issue once my coding 
is done and
ready to deploy which I'm no where near close to yet.  As for my 
timeline, I'd love
to move all of my existing functionality over to Seaside/Smalltalk soon 
which would
mean that I don't have to support my two other PHP sites anymore (an old 
"v1"
prototype site and a v2 "user" site).  As for my range of functionality, 
there are admin
features that the average user won't have access to (or see for that 
matter) such as
adding users, locking out users, generating admin reports, entering 
manual paper
orders, handling back-orders, etc.  All of this should be able to pass a 
CSS validation
and be XHTML 1.0 Transitional as a minimum.. I spent quite a bit of time 
generating
valid code and from what I've seen, Seaside does a nice job in this area 
as well (some
frameworks that generate HTML on the fly don't generate valid XHTML).  
Anyway,
hopefully someone will chime in with some more comments on this thread.. 
:-)

-- Rick