Thanks for looking into it. Please let me know if you have any ideas. Regarding dynamic views, its a little more complicated than I may have described clearly. By prototypal I mean that different instances (objects) with the same entity (class) may have more or fewer slots, depending on arguments provided at the time of instantiation. Slot-values may be computed (dataflow, like cells) or computed differently, or statically assigned, on a per instance basis. Further, the archetypal properties common to all instances of a given entity may dynamically changew based on the definition of new relations (associations). Its a really fascinating system and believe it or not i've had a good experience in terms of the robustness and stability of object model based on it. Unfortunately, I havent been quite as won-over by the hu.dwim.web-server/hu.dwim.presentations framework (although it does have certain strengths and certainly has potential). So thats my interest in weblocks, which I think would be an excellent alternative, entity-relation sacrifice notwithstanding...
As such, i'm pretty sure I'm not quite up to the challenge of implementing support for such a thing in weblocks, at least not yet. It is on my wish list though so I'm definitely keeping it in mind as i study weblocks source. On Wednesday, January 23, 2013 3:34:36 PM UTC-5, Scott L. Burson wrote: > > On Wed, Jan 23, 2013 at 6:48 AM, Dan Lentz <[email protected]<javascript:> > > wrote: > >> My issue is in getting updates and insertions to work properly. I have >> very good results for all kinds of views (grids, forms, mixins etc) for >> objects that I manually populate my database with. However I seem to be >> missing something crucial with regards to, say, updating a >> persistent-object from a drill down form. After editing the form and >> clicking submit, the cancel button greys out, but the form does not >> disappear and the database is not updated. Is there some extra >> customization required to something like a data-form-on-submit :after >> method? >> > > Hmm, that's odd. Glancing at your code, I don't see anything obviously > wrong. I haven't used gridedit myself, though. > > >> Also, far less critical at the moment, I don't seem to be able to enable >> the checkbox column to select items from my grid edit. I haven't spent >> much time on this, but I do specify :allow-select-p T when instantiating >> the widget. Is something else required? >> > > I've never tried to use that either, but I'm surprised it doesn't work. > > I'll look into both of these things, but it may take several days. > > >> And finally, I originally had aspired to support the entity-relationship >> metaclasses as in hu.dwim.meta-model, which are really quite powerful, and >> add a kind of prototypal dynamism to the persistent-associations >> object-model (a little like an RDF store). Unfortunately, from what I've >> seen it doesn't look like weblocks will accommodate that type of dynamism >> (at least without some additional help). Views, for example, would have to >> be dynamically recompiled when needed. I'm not sure if this is even >> reasonable, and I'd have to study hu.dwim.metamodel a bit further to see >> where I might even find a hook to use for triggering such a thing. This >> is a low priority, but I'm interested if there are any ideas out there for >> the weblocks side of the matter. >> > > I don't know anything about hu.dwim.meta-model, but generally speaking, > instantiating your own views at runtime doesn't seem unreasonable to me. > Take a look at the code for DEFVIEW-ANON to see how to do it. > > -- Scott > > >> If anyone is interested in having a look at the existing weblocks-perec >> store driver code and weblocks-perec-demo code as it stands I created a >> fork on github: http://github.com/danlentz/weblocks/ >> >> Thanks everyone, >> Dan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "weblocks" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/weblocks/-/L8UfnJzIR2cJ. >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/weblocks?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. Visit this group at http://groups.google.com/group/weblocks?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
