> >> Right! I am the user and I speak for formalchemy. > > I'm not sure what you mean when you say "speak for formalchemy". >
I meant I'm using formalchemy to deal with my forms, I like it and want to make my job with help of it. Suppose that is the rule of the game. >> I'm inclined to do so, but still as the user I want related stuff be >> visible on parent view. May be partially, but visible. > > You can still make it visible, but not editable. Just do it in the > templates. I don't see why you need to make a "read-only renderer" to > do this instead of just doing the rendering directly in a template, > perhaps using a helper function for stuff such as rendering > dates/times or slightly more complex HTML. For forms, I can understand > using something like a form library to help with rendering as you want > to make sure you have a simple way to serialize the form results into > an entity. But for strictly read-only text or other HTML that isn't > fields on a form, I'd just keep that to the template. > formalchemy is a form library. It introduces "fieldsets", which can be rendered. Each field composing a fieldset has mentioned two renderers. The process of visualing of fieldset is just iterative calls to these renderers. So in this coordinate system 1-M relation is field and, to avoid inconsistency, I should provide these renderers. Formalchemy' defaults here to render a multibox. I consider this widget as foobar, so let's invent a better presentation. The low-hanging fruit is to *reuse* fieldset renderer of related entity. The question is how to determine the boundary conditions of this approach. >> >> Exactly. Suppose I want to CRUD images related to an object. The >> situation is hardened here since images (along with other uploaded >> stuff), as indirectly accessed objects, should in addition be provided >> with interface to upload them. How would you do that? >> > > I am not understanding you fully. My main worry is that you're trying > to take DRY too far, which is a problem that that I know hounded me > for awhile, and still sneaks into my thought process. Yes. I hate repetitive mess like copy-pasting. > But I guess it > would be helpful to know your use case a little better. > Well, a variable length attachment list connected to a particular entity of my model. It is in fact *the main* column of the entity. To be specific, a property object is stored along with scan-copies of related documents. The assumption is that potentially several hundreds of them can exist. Each attachment should be commented, filtered, sorted, easily accessible with a click. A strong condition of no-page-reloads is set. My first thought was to trick and to wrap such a "bad" data in a simple <textarea/> with some kind of JS rich editor :) This would solve at least two problems: arbitrary commenting and ease of access. I advanced there, but still filter/sort remains. What could be done here? TIA, -- Vladimir -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
