Glad to hear. Also see mapper.view.ItemsList (anyone have a better name?), which is used by TableEditor. It's a similar idea without relationships. Should MappedOne/ManyToMany be based on ItemsList? Also should I take Mapped out of those names? After all, they're not MappedFields and they don't correspond to a table column.
------------------------------------- Magnus Alvestad<[email protected]> wrote: This work that you've done in Mapper fits in very well with something I've been planning to do. In a Java project some time ago we implemented a 'change engine'. We were loading big pension agreements, manipulating them in a web interface and finally saving them back to the database. While the user was working on the agreement, we generated a list of changes, containing enough information to replay or unroll the change. We could use this to implement undo and some semi-intelligent merging when two users were trying to commit changes to the same agreement. We also let the user review his changes before saving, and we indicated changed fields visually. We were even thinking of implementing some kind of macro or replay functionality, but never got that far. I've been trying to implement something similar as a lift component, but with the old relationship handling it wasn't practical. With your changes it should be. Thanks! -Magnus On Jul 27, 9:57 pm, Naftoli Gugenheim <[email protected]> wrote: > I committed some code last night, which can help building mapper-based view snippets, with G-d's help. It includes the following classes: > (1-2) net.liftweb.mapper.OneToMany, ManyToMany: Gives a more object-oriented approach to managing related entites. You can manage the many side of a 1-n and n-n as a mutable collection of children, and the parent of a child can be set directly, instead of via its id. And the children are not saved to the database when you add them until you call save on it or its parent, nor deleted when you remove tem until you call delete_!, which is very helpful when you need to keep track of adds/removes through multiple requests. For example, if you are displaying a list and you can click delete, but it shouldn't be permanently deleted until you click save. > There is a new package, ...mapper.view, which contains a number of utilities for mapper-based views: > (3-4) ModelView and ModelSnippet provide a number of building blocks for views that are too complex to CRUDify. Inherit ModelSnippet (which extends StatefulSnippet) and wrap your entities in ModelView (view is used in the sense of a wrapper). > (5) Util provides some more building blocks that just be imported, without needing a ModelSnippet context. > (6-7) Paginator makes it easy to create paginated, user sortable listings. You can use PaginatedSnippet instead of ModelSnippet to help. > (8-10) ItemsList lets you manage a list of entities with pending additions and deletions. It's used by TableEditor, which is a very easy to use and customizable snippet to edit tables directly. It's useful for editing short lists, e.g., a lookup table like cities. Don't forget to register the table in Boot. > (11) Then there's the experimental FormProcessor, if you need your form to be processed in one block instead of separate closures, e.g., to surround with try. > (12) Also experimental is sitemap.XmlMenu which lets you write menus in xml. > (13) I may add CaseEnum, which lets you write case classes that automatically double as an Enumeration. > Questions, comments, suggestions, and constructive criticism are more than welcome! > Thanks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" 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/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
