On Sat, May 2, 2009 at 12:35 PM, Andrew Scherpbier <[email protected]>wrote:
> > David Pollak wrote: > > > > > > On Thu, Apr 30, 2009 at 10:48 PM, Andrew Scherpbier > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > The "Getting Started" document got me hooked on Lift. :-) > > I guess I'll report my struggles from there. I don't know if what > > I did > > is typical. > > > > After actually running the two examples from the "Getting Started" > > docs, > > I looked and found some other examples, did some looking around in > the > > mailing list archives and started reading the "Exploring Lift" book. > > As a starting application of lift, I want to write a simple purchase > > order tracking webapp. It was easy enough to figure out how to > > hook up > > PostgreSQL instead of Derby. I started experimenting with the > CRUDify > > trait and got several tables working, but then I got stuck trying to > > make a more cohesive app. What I could not figure out was how to use > > CRUDify's functionality without having to put all the options in the > > SiteMap. So I spent a lot of time trying to figure out the SiteMap > > class. I have since come to the realization that I probably > shouldn't > > be using CRUDify, as non of the examples actually use it. I have > also > > realized that I should be putting rules in LiftRules.rewrite. > > > > > > I don't think so. I think that you should be using SiteMap. SiteMap > > is the best tool for defining site navigation and access control rules > > around. > > > > CRUDify and ProtoUser are like scaffolding... they get you some pieces > > really quickly, but you'll ultimately need to replace them. You > > should never have to replace SiteMap. > > > > So... what's the specific challenge you're running into with SiteMap? > > > The first challenge I had was trying to figure out how to keep the > functionality of CRUDify, but not the menu items. The docs state that > you can override defs. ie: > > *createMenuLoc* |def createMenuLoc| > The menu item for listing items (make this "Empty" to disable) > Box <javascript:void>[Menu <javascript:void>] > > > But I don't want to disable it, just hide it from the menu. > Then, failing that, I wanted to put the menu items in a sub-menu in the > SiteMap. I wasn't able to accomplish this while keeping the CRUDify > functionality functioning. (The submenu seems to always to add a level > to URI but the CRUDify trait doesn't know about that? I could be > grossly wrong, of course!) Super-menus and sub-menus share no URL information with each other. A super-menu could be at /foo/bar/baz/super and sub-menus could be at /dog and /cat > > Ultimately, in the app I'm trying to build, CRUDify would only be useful > for the main record type. Most other records have a 1-n relationship > with the main record. It is unclear to me how to use CRUDify in this > situation. (I can use CRUDify to add a PO, but how do I use CRUDify to > add SKUs to a specific PO?) CRUDify is for building simple CRUD apps. It's not meant for complex relationships. Until someone comes up with something better, you'll have to hand-code the relationships and the screens for the relationships. > > > So, looking at the pocketchange app which has this kind of record > relationship as well, I figured that CRUDify was not the right > solution. (I hope I'm wrong, because I like what CRUDify provides!) Sorry. David > > > > > > > So, my point, I guess, is that it was never clear to me what request > > rewriting was all about. I didn't understand the explanations and > > basically just skipped it and tried to do everything with SiteMap. > > What I have taken away from this: "Request Rewriting" sounds very > > advanced and made me think of sendmail rewriting rules! (Yuck!) > > Maybe it would be good to have some blurbs on "Lift for JEE > > developers". What is the equivalent of mapping a URL to a servlet > and > > how do you deal with the URL pattern matching. (I want to map > > "/foo/*" > > to a some soft of action) > > > > So that would then be a nice lead-in to coverage of > > net.liftweb.http.S, > > right? > > > > Anyway, back to API docs, it never occurred to be to look at the docs > > for net.liftweb.http.LiftRules! There are actually lots of comments > > there. The "rewrite" is kinda hidden there, so it probably should be > > called out in the class docs. Then for the actual "rewrite" docs, it > > would be nice to give some examples of what should go in there or > > provide a link to external docs showing the same. > > > > How have other people tackled the learning curve of lift? > > > > --Andrew > > > > Derek Chen-Becker wrote: > > > In terms of the API docs part of it would just be expanding on the > > > current scaladoc to provider better explanation. Obviously there > > are a > > > ton of classes to document, so I'd like to focus efforts on getting > > > the most bang for the buck. I was thinking of starting with > > > net.liftweb.http.{LiftRules,S,SHtml} and making the documentation > on > > > them *outstanding*. We can branch out from there. If you're > > coming to > > > Lift new, it would also be helpful to find out what we're missing > or > > > need to cover better in the "Getting Started" document on the web > > > site. If you want to read through that and provide feedback here on > > > the list that would be great. > > > > > > Derek > > > > > > On Thu, Apr 30, 2009 at 12:20 PM, Andrew Scherpbier > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > > > > > > Derek, > > > That's awesome. I want to help. What can I do? I can > > start by proof > > > reading stuff. > > > > > > --Andrew > > > > > > > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
