Some questions regarding my experimental perec web locks-store

[Dan Lentz]

I've been playing with a driver for hu.dwim.perec, but I have a couple of questions and I'm hoping perhaps members of this group more familiar with the view machinery of weblocks might be able to point me in the right direction. I've based the driver more-or-less on the weblocks-elephant store, as that seems to be the closest match to what perec requires: Dynamic transactions and (at least for now) the persistent-proxy mechanism.

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?

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?

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.

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

[Dan Lentz]

Ok after thinking some more my guess for issue 1 is to specialize dataform-submit-action for ((obj dataform)(data persistent-object) &rest args) to call #'update-object-from-request -- but I cannot seem to find update-object-from-request so I'm clearly working with outdated knowledge of weblocks API or hallucinating, probably both. Does this ring a bell for anyone? I feel like I'm getting closer, but still not success yet...

Dan

[o_z]

среда, 23 января 2013 г., 17:59:33 UTC+2 пользователь Dan Lentz написал:

Ok after thinking some more my guess for issue 1 is to specialize dataform-submit-action for ((obj dataform)(data persistent-object) &rest args) to call #'update-object-from-request -- but I cannot seem to find update-object-from-request so I'm clearly working with outdated knowledge of weblocks API or hallucinating, probably both. Does this ring a bell for anyone?  I feel like I'm getting closer, but still not success yet...

Dan

There is update-object-view-from-request instead of update-object-from-request.

As I've read I'm interested in what will be if we set some slot of already persisted object ?

WIl it persist this value ? If no then it needs to be implemented since it is how it work with other stores.

[Dan Lentz]

Setting a slot of already persisted object should persist the value, as long as I've gotten the persistent proxy magic correct (works great for read-only use currently and I think should not be the problem). I will investigate u-o-v-f-r-d. I did see it, but I'm not sure why it should be necessary though since I don't see it in the elephant driver?

[Dan Lentz]

Also I've got PERSIST-OBJECT traced, and it is not called when I SUBMIT on a dataform, so the problem is before any of the persistent-proxy persisting gets involved

[Scott L. Burson]

On Wed, Jan 23, 2013 at 6:48 AM, Dan Lentz <DanL...@gmail.com> 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 webl...@googlegroups.com.
To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.

[Dan Lentz]

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.