David Pollak wrote:
>
>
> On Thu, Apr 30, 2009 at 10:48 PM, Andrew Scherpbier 
> <and...@scherpbier.org <mailto:and...@scherpbier.org>> 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!)
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?)

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!)
>
>
>     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
>     > <and...@scherpbier.org <mailto:and...@scherpbier.org>
>     <mailto:and...@scherpbier.org <mailto:and...@scherpbier.org>>> wrote:
>     >
>     >
>     >     Derek,
>     >     That's awesome.  I want to help.  What can I do?  I can
>     start by proof
>     >     reading stuff.
>     >
>     >     --Andrew
>     >
>


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to