David,
I'll take a look at the ESME code to see if what you've done scratches
my
itch on this issue. I've run the war file and it looks interesting. I
assume the source is
also available. Thanks for the heads-up.
Glenn...
On Aug 27, 7:55 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> On Thu, Aug 27, 2009 at 2:00 PM, glenn <gl...@exmbly.com> wrote:
>
> > David,
>
> > Besides the very detailed discussion here about the problems of Boot
> > initialization
> > and the immutability of sitemap and liftrules, that strikes me as a
> > sufficient
> > barrier to real modularization.
>
> Are you talking about modularization of web apps? Are you talking about
> being able to "plop in" a JAR file and do one or two bits of configuration
> and have that JAR's features be part of your app? If you are, with the
> exception of the "where do my menu items go" issue, as long as you can do
> the configuration in Boot, Lift allows for fully modular apps.
>
> Rather than complaining the Lift doesn't offer what you need, please define
> what you need in very specific terms (I need to intercept a GET request to a
> URL, I need to intercept requests to a URL if certain conditions are met, I
> need to include a tag in view code that invokes code in my module, etc.) or
> point to another framework that allows for this plugin modularization.
>
> > I hadn't thought about turning
> > reuseable code into
> > traits and assigning those around in jar files until you mentioned it.
> > Not a bad idea.
>
> > But I wouldn't feel comfortable incorporating third-party traits in my
> > code unless
> > I had the source to fall back on.
>
> Why are traits any different than objects that you subclass? As far as I
> can tell, traits simply give you nearly multiple inheritance without the
> headaches. Why would you be any less willing to mix in a trait than to
> subclass a class provided by another library?
>
>
>
> > Example of poor encapsulation - just the fact that you can encapsulate
> > snippets and templates. Without the
> > source, how can a user ever hope to incorporate those.
>
> I think that snippets are a near perfect encapsulation mechanism. They are
> simply a transformation of XHTML -> XHTML. What could be more straight
> forward? What could be more encapsulated? Further, Lift's mechanism of
> associating HTML elements with functions means that there's no need to have
> special URLs to handle forms or anything else. My snippet can generate a
> form that will be processed if it is submitted back to the server, no matter
> what URL the form is submitted to. In Rails and other MVC frameworks, the
> POST/GET must be done to a specific controller in order for the parameters
> to be correctly processed. Why does this matter?
>
> Well, in the ESME codebase, I just created an authentication plugin
> mechanism that allows a plugin to define a part of a form that is to be
> filled in as part of the signup process. The signup process doesn't know
> anything about the plugin or what fields the plugin needs. The snippet that
> handles the signup simply binds one element to the plugins part of the
> sign-up. The plugin manages its own portion of the form, manages its own
> validation, manages its own saving, all without having to register as being
> part of the controller. This is highly modular.
>
> > And then, to
> > make them private, which is done...that's turning
> > a headache into a nightmare.
>
> Can you give me an example of a private snippet or a private template and
> how you would use one?
>
>
>
> > Yeah, as long as you work at the source-level, there is no problem.
> > But that, in-and-of itself, is the problem. As you
> > suggest, some, as yet unilluminated patterns, would be most helpful.
>
> If I understood what you were trying to do, I could help you with patterns.
>
> Code works best for me. If you could put together templates and stubbed
> Scala and make clear what you're trying to do and what Lift is not letting
> you do, I could help you out.
>
> Thanks,
>
> David
>
>
>
> > Glenn...
>
> > On Aug 27, 12:11 pm, David Pollak <feeder.of.the.be...@gmail.com>
> > wrote:
> > > On Thu, Aug 27, 2009 at 11:22 AM, glenn <gl...@exmbly.com> wrote:
>
> > > > David,
>
> > > > Returning menu items from your init function is OK, but forces the
> > > > user
> > > > of your module to guess on function-call order
>
> > > I don't understand... what function call order are you talking about?
> > The
> > > order in which the modules are initialized? Something else?
>
> > > > , or be forced to glean
> > > > it from
> > > > the source, which he should not be required to do.
>
> > > > Putting code such as this, instead, in your init function helps, but
> > > > does not eliminate that problem.
>
> > > What particular problem?
>
> > > > val sitemap = LiftRules.siteMap match {
> > > > case Full(sm) => LiftRules.setSiteMap(SiteMap(sm.menus :::
> > > > Role.menus:_* ))
> > > > case _ => LiftRules.setSiteMap(SiteMap(Role.menus:_*))
> > > > }
>
> > > Where are you proposing to put this code?
>
> > > > With it, you can sort of standardize your call-order, requiring that
> > > > the init function
> > > > be called immediately before
>
> > > Just to be precise, init() is a method on your module. It's not a
> > function.
>
> > > > S.addAround(DB.buildLoanWrapper)
>
> > > > in Boot,scala.
>
> > > > But, there is a larger issue at stake here, I fear, and that is that
> > > > true modularization
> > > > requires adherence to rules of encapsulation and complete
> > > > documentation, two things
> > > > that are problematic in Scala code (perhaps due to its power and
> > > > complexity), unlike pure OOP.
>
> > > Ummm... as far as I know, Scala is a pure OO language. Everything in
> > Scala
> > > is either the instance of a class (and object, but object is overloaded
> > with
> > > Scala's use of it as a keyword for singleton) or a method. There is
> > nothing
> > > else in Scala. In this way, Scala is like Smalltalk and Ruby. It's not
> > > like Java where things exist in Java that are neither an instance nor a
> > > method (static methods, primitive types, etc.)
>
> > > There is nothing that we can't do in Scala to encapsulate anything... the
> > > issue that I see is "what do you want to encapsulate?"
>
> > > > When I've written before on this subject in this group, I've gotten a
> > > > lot of examples in the small
> > > > purporting to dispute my contention, but falling short. If you know
> > > > I'm wrong, fine ... let's see it.
> > > > If you just think I am, well...think harder.
>
> > > Let's separate Lift from Scala the language for a moment. I'm no expert
> > in
> > > PLT so I'm not going to argue encapsulation in Scala.
>
> > > I can argue about Lift's modularization and what its limitations are.
>
> > > The following things in Lift I know to be non-modular:
>
> > > - Mapper: because one cannot subclass Mapper definitions, it's not
> > really
> > > modular. Yes, I've built (and subclassed) ProtoUser, but it's a huge
> > hack
> > > and anything serious (e.g., subclassing an existing mapper and
> > *changing*
> > > the behavior of one on the fields) is not doable with Mapper. This is
> > > basically because I've never meant Mapper to be a serious OR mapping
> > tool,
> > > but more of an ActiveRecord clone where you can create a mapping
> > between an
> > > RDBMS and some sort of "record". I use Mapper very successfully, but
> > it's
> > > not meant for the same things OO is meant for (subclassing) or what
> > Mixins
> > > are meant for.
> > > - SiteMap: SiteMap is frozen at boot time. This means that OSGi
> > modules
> > > can't load and unload themselves and mutate the sitemap. Because the
> > > sitemap is fixed at boot time, it's also not possible for a module to
> > insert
> > > menu items at an "appropriate" place in the menu hierarchy.
> > > - LiftRules: like SiteMap, the LiftRules are fixed at boot time. It's
> > > not possible for modules to load/unload dynamically and change the
> > various
> > > PFs dynamically.
>
> > > I have a plan for fixing the LiftRules stuff so we can fully support OSGi
> > > modules. I will likely extend that to supporting more dynamic sitemaps.
>
> > > More broadly, every time I've had Scala code that's "concrete" and needed
> > to
> > > be made more runtime dynamic, the process has been simple, quick, and
> > > painless. Breaking classes into traits and composing those traits into
> > > different runtime configurations has by and large been a few minute to
> > few
> > > hour project. Yeah, it may be considered "poor mans" DI to use traits
> > and
> > > the cake pattern, but I find that the type safety that Scala offers makes
> > > the small extract Scala coding effort to be worth it vs. writing more
> > > tests/configuring more runtime stuff/the weird errors that creep into the
> > > code despite tests.
>
> > > > This is not small potatoes There are plenty of languages on the dust
> > > > heap precisely because
> > > > of the extension problem.
>
> > > Can you be very detailed about what kind of problems you're seeing.
> > Maybe
> > > the folks on this list can help you work through them and maybe we'll all
> > > discover new Scala patterns.
>
> > > Thanks,
>
> > > David
>
> > > > Glenn...
>
> > > > On Aug 26, 2:53 pm, David Pollak <feeder.of.the.be...@gmail.com>
> > > > wrote:
> > > > > On Wed, Aug 26, 2009 at 10:13 AM, glenn <gl...@exmbly.com> wrote:
>
> > > > > > Timothy,
>
> > > > > > I'm still not convinced that Lift applications can be modularized
> > as
> > > > > > simply as you suggest.
> > > > > > Do you have any samples of your MyLib.init? How do you handle the
> > non-
> > > > > > PF's, like schemify and setSiteMap?
>
> > > > > I typically return my menu items from my init function. You can call
> > > > > schemifier from within your init function.
>
> > > > > > As for templates, I've learned that you can use the templating
> > > > > > mechanism in Loc to eliminate the need for
> > > > > > html files, but that's only a small part of the problem.
>
> > > > > > Glenn...
>
> > > > > > On Jul 27, 4:01 pm, Timothy Perrett <timo...@getintheloop.eu>
> > wrote:
> > > > > > > Hi Glen...
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
