I have to agree with Richard on having soup-to-nuts examples on real-
world/pragmatic implementations of Scala/Lift.

We're all here because we 'believe' in Scala and Lift, it's just that
those who are just starting (like me and Richard) would like to see
examples on how to implement Scala/Lift in non-trivial, real-world/
common applications.

And that's more to see how to shift our 'perspective' from {insert-
framework-here} to a Scala/Lift approach.

I've been tentatively (after reading 'Programming in Scala' and
devouring any Scala and Lift tutorial/article/beta-pub) starting a new
project trying to use Scala/Lift and I've been stymied by a 'paralysis
of analysis' to try to use the complete power of Scala/Lift (FP, etc)
out the gate.

I've now decided to just get something going even if I have to use
imperative patterns and Java OO modeling, and just refactor and refine
later.

A non-trivia sample application development would be oh-so-helpful in
addressing the 'hows' and 'whys' of the mundane plumbing in Scala/Lift
without falling back into the Java comfort zone.

I'd also like to thank James M. for putting into a post most-
everything I think (from a newcomer's perspective) is needed for a
wider adoption of Lift.

Specifically, his third (#3) point of having a more thorough and
accessible coverage of having Lift in a real-world development
environment.

The seventh (#7) point of have 'recipes for Lift' would also be
extremely helpful.  Maybe even a 'FAQ' style HOW-TOs format for the
'recipes' and the explanation behind why it was done (if applicable) a
certain way as opposed to a straight Java/Ruby/Python/whatever
translation.

I think many times the people who know a topic (like Scala/Lift)
inside and out tend to have a 'blind spot' to what the newcomer might
need, thinking that 'this' or 'that' is so obvious, why would it need
to be documented or explained?

I know I've done that myself with Java and some frameworks.  I can't
answer the question, "What book should I get to learn Java?" because I
just don't know anymore.

It is refreshing to see that the many people in the Lift community
know this and ask the 'refugees' what's needed to ease the transition.

I want to thank everyone in the Scala/Lift community for all of their
work and I hope to be able to contribute once I get up to speed.

As to the registration, I don't find it a big deal.  You can lock down
certain topics (to be edited by only users in certain groups) and
leave other topics open to public editing.  MediaWiki has the
flexibility and it would make sense to have a 'mixed' editable
paradigm since the wiki is not Wikipedia and has a particular focus.

Keep up the good work,

Greg

On May 4, 8:23 am, "Charles F. Munat" <c...@munat.com> wrote:
> James,
>
> This looks more like about $20, but I'm not complaining. Your thoughts
> mirror mine in many ways. #4 is a very good idea. Even just a list of
> what is needed. Folks could add to a documentation wishlist, and then
> anyone who thought he or she could tackle an item could just do it.
>
> I'm glad that people are finally responding to this thread. I was
> beginning to think that I was on my own...
>
> Chas.
>
>
>
> James Matlik wrote:
> > Hello Charles,
>
> > This is good news.  I'm sorry I didn't see your initial email going out,
> > but I would guess it is better late than never.  I think the first thing
> > that needs to be done is to clearly define what is to be documented in
> > the wiki and where.  Here is my 2 cents:
>
> >    1. There should be a page linked to the wiki's main page providing
> >       marketing style information.  This could be a kind of "About Lift"
> >       page on steroids.  What makes Lift novel?  What features does it
> >       provide that simplify the state of the art in web development?
> >       How easily can the technology be integrated with legacy
> >       deployments?  What design goals does Lift strive for and why?
> >       Does Lift have a viable future?  What is Lift's stance on KIR
> >       support?  Once an official release is made public, will bug fixes
> >       be applied to that version going forward and for how long?  How
> >       stable is the API?
> >    2. A brief description of the Lift culture could be beneficial; a
> >       kind of "welcome to the party, this is how we roll" for the
> >       uninitiated (I'm still figuring it out).
> >    3. Make a clearly defined section for people developing applications
> >       with Lift.  Give a 100ft view of the code/compile/deploy/test
> >       development cycle, then delve into the tools that make this cycle
> >       simpler.  Provide the basics on Maven, what it is, what it does
> >       for Lift, and the commands of interest for Lift development.
> >       Describe how Maven is not required for the Maven adverse, and
> >       provide instructions on how to proceed without Maven (maybe an
> >       opportunity for sbaz?).  Up-to-date HowTo documents on standing up
> >       different editors (Nebeans, Eclipse, Idea, etc.) are important.
> >       How should Lift be deployed?  What are the required dependencies?
> >       Is it reasonable to simply use Maven's jetty:run target for a
> >       production deployment?  What are the common configuration settings
> >       for various servlet containers for development vs. production
> >       deployments.  What architectures should be used for scaling out
> >       deployments for redundancy and performance (serialization,
> >       Terracotta, load balancing, etc.)?  Development, deployment and
> >       KIR overview for those familiar with Rails but not with Java.
> >    4. A documentation TODO list for people to contribute.
> >    5. Are there any best practices?  Some good topics could be I18N, how
> >       to avoid introducing security vulnerabilities like cross site
> >       scripting or SQL injection attacks, how best to leverage templates
> >       for CMS-like systems with very large numbers of unique pages vs.
> >       applications with a relatively short list of screens, security and
> >       performance tuning.
> >    6. There needs to be a very clear division between documentation for
> >       public reference and works in progress/new feature collaboration
> >       that would only confuse people.
> >    7. There is a lot of good example code in the lift demo app.  It
> >       might be nice to provide some supplemental annotated documentation
> >       in the wiki (a lot of people don't turn to the code by default).
> >       This could be a kind of "recipes for Lift" section that could
> >       contain all kinds of examples including those in the demo app.  As
> >       people contribute creative solutions or solutions to common
> >       problems, they could eventually be pulled into the demo app.
>
> > I'm sure some of this already exists on the wiki, but it would nice if
> > the navigation made it easier to find.
>
> > As for registering with the wiki, could OpenID be supported for the wiki
> > account?  I'm seriously tired of creating new accounts all the time with
> > the same unchanging handful of passwords that I regularly have to cycle
> > through when accessing my account.  I'd like to see OpenID implemented
> > everywhere.
>
> > On Tue, Apr 21, 2009 at 3:38 PM, Charles F. Munat <c...@munat.com
> > <mailto:c...@munat.com>> wrote:
>
> >     I am charged with coming up with a site map/information architecture for
> >     our hopefully-soon-to-be-updated wiki.
>
> >     What would most benefit you on a documentation wiki? What sorts of
> >     things are you having the most problems with?
>
> >     Please submit suggestions for a wiki outline, as well as any other ideas
> >     you have. For example, ideas on wiki structure are welcome. You could
> >     even suggest your own outline.
>
> >     Please participate! Yes, you, lurker! We want to know what you need.
>
> >     I'll collect all the ideas this weekend, consolidate them, and present a
> >     suggested outline (road map) for the documentation wiki.
>
> >     Thanks!
>
> >     Yes! If you are reading this, then I am talking to you. Speak up.
>
> >     Chas.- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
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