that handles all this stuff for me.
I was thinking along the lines of
after the quick toggle post:
project.init(projectid=attributes.projectid, togglesetting=attributes.togglevalue);
project.save("settingOne");
since I already have the projectID and the setting to save at the client side when I post the request I wouldn't have planned on reading the project data again (at least not at that point in the process perhaps).
However, as I type this I think - what the heck, most likely with the example I gave, I'm going to need the full project data anyway in order to display the page the quick toggle UI control was on (wouldn't make sense to send the user somewhere else) so getting the whole project back, setting some values, updating the database, then displaying the projects settings to the user would be just as effective as setting up the project object with just my values, updating the database, fetching the project details, then displaying them to the user.
while I am sure there might still be some small times where I would only want to update a specific portion of the record without the overhead of downloading the entire record, it seems, after further consideration, that the times when I would need/want to do that are less than I initially suspected.
Thanks,
Bill
On 2/9/06, Joe Rinehart <[EMAIL PROTECTED]> wrote:
Hey Bill,
Either way (allowing partial commits or not), the bean is still going
to be fetched and populated - that's just kind of the breaks of
dealing with things as objects instead of writing ad-hoc SQL. It's
not as granular, but it's also more powerful.
If you do allow a partial commit from the "settings" interface for the
project, you'd likely have something like this (assuming Model-Glue
(or Mach-II) event-bean utility):
project = project.load(projectId=projectId)
project.makeEventBean(project)
project.save("settingOne,settingTwo")
Without a partial commit, it'd just be this:
project = project.load(projectId=projectId)
project.makeEventBean(project)
project.save()
That'd execute the (slightly more efficient) "partial" SQL that just
updates settingOne and settingTwo. However, it's violating the DRY
(don't repeat yourself) principle that frameworks like Reactor help
implement. If you don't allow partial commits, you can add
settingThree by just adding a new database column and UI: the "full
stack" nature of combining Reactor with Model-Glue or Mach-II makes
this possible, because your Controller code doesn't know anything
about columns.
In the end, everything's a tradeoff.
-Joe
--
Get Glued!
The Model-Glue ColdFusion Framework
http://www.model-glue.com
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
