David,
For all that you've said in defense of Lift's extensibility, answer
one question:
Could you override def _showAllTemplate in Crudify, without having
the source
at your disposal? And, this is not an isolated example.
Glenn...
On Aug 28, 12:05 pm, AlBlue alex.blew...@gmail.com wrote:
On Jul 29, 12:55 pm, Heiko Seeberger heiko.seeber...@googlemail.com
wrote:
Just a quick and dirty reply: In order to get OSGi support LiftRules should
delegate *everything* to a Collection of LiftModules. LiftModules can be
added to and removed from this collection anytime.
Yup, maintaining
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:
David,
Returning menu items from your init function is OK, but forces the
user
of your module to guess on function-call order, 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
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
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. I hadn't thought about turning
reuseable code into
traits and assigning those around in jar
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
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?
As for templates, I've learned that you can use the templating
mechanism in Loc to
Hey Glenn,
I actually don't use those features in my libs... For reasons I wont go into
that's just not what my kind of work involves... So I cant really comment
from experience im afraid.
Cheers, Tim
On 26/08/2009 18:13, glenn gl...@exmbly.com wrote:
Timothy,
I'm still not convinced
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
Hi all,
This is a very good discussion!
As I am trying to provide OSGi support for Lift, I already encountered this
booting/resolving issue. If we could go for OSGi-only this would be a
straightforward task (like Stephen described), but we have to support both
worlds: Static monolithic non-OSGi
Hi all
I'm completely new to Lift (and Scala) so I'm not yet very familiar
with the Lift-specific needs regarding modularization. But I just come
from an OSGi project and would like to share two experiences I've had:
* Usually OSGi handles classloading very well. Where you can run into
problems
Arthur,
Thanx for sharing your experiences!
Please find my comments below ...
Heiko
2009/7/29 Arthur avand...@gmail.com
Hi all
I'm completely new to Lift (and Scala) so I'm not yet very familiar
with the Lift-specific needs regarding modularization. But I just come
from an OSGi project
-1 for adding modules by dropping in a jar
Suppose the jar supplies multiple Lift modules and I only want to use
one, or suppose I want to use some other class in the jar and don't
want to use any of its Lift modules.
Adding a module to a Lift app really should be an explicit action by
the
Ryan,
I agree with you for the most part - certainly making it explicit would be
my preference also.
Im not 100% sure that we would need to replicate all the LiftRules
functionality as a trait for plugins, as that's just one aspect of how a
plugin could change the environment.
Your point about
Just a quick and dirty reply: In order to get OSGi support LiftRules should
delegate *everything* to a Collection of LiftModules. LiftModules can be
added to and removed from this collection anytime.
Heiko
2009/7/29 Timothy Perrett timo...@getintheloop.eu
Ryan,
I agree with you for the
More spitballing...
Tim,
I really don't know which LiftRules stuff would need to be included.
For other types of environment changes, the trait could have onLoad
and onUnload methods.
Heiko,
Maybe it is possible to make such a change without breaking API,
though I am still fairly new to Lift
Sounds good!
Any ideas how class lookups (snippets at least) could be delegated to
various modules. Currently Lift is using the *global* classpath in a fashion
that makes it really hard / impossible for OSGi.
Heiko
2009/7/29 Ryan Donahue donahu...@gmail.com
More spitballing...
Tim,
I
@Heiko:
Im not sure we would need to lookup snippets, as the module creator could
just register them with LiftRules right? (think DispatchSnippet etc)
@all:
I think we need to take a step back here a second: Everyone wants a plugin
system, but not everyone wants OSGi (specifically the
For that price you could write com.mypackage.Init etc.
-
Timothy Perretttimo...@getintheloop.eu wrote:
@Heiko:
Im not sure we would need to lookup snippets, as the module creator could
just register them with LiftRules right? (think DispatchSnippet etc)
Bah, that's very true Naftoli...
On 29/07/2009 16:33, Naftoli Gugenheim naftoli...@gmail.com wrote:
For that price you could write com.mypackage.Init etc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift
LiftRules.addToEnviroment(com.mypackage), and the com.mypackage conforms to
a known standard / format with some special traits that we call loading
methods on.
This isn't really any different then building a module by extending
LiftModule trait except that the known standard / format' is
This discussion has gotten beyond a simple solution for Lift plugins.
Most Lift apps now don't use OSGi, and
modularization means something different in a non-OSGi environment.
For one thing, it's not dynamic. You still
have to code to use the new module. A well-mannered Lift/OSGi marriage
is a
Glenn,
We have got OSGi support on the roadmap for 1.1, hence IMHO this has to be
addressed right now.
Heiko
2009/7/29 glenn gl...@exmbly.com
This discussion has gotten beyond a simple solution for Lift plugins.
Most Lift apps now don't use OSGi, and
modularization means something
On Tue, Jul 28, 2009 at 12:10 PM, glenn gl...@exmbly.com wrote:
Hi, Ross,
So, with the changes, where would templates need to be placed in jar
files in
order to be found - or can they be put in any directory as long as the
resource
is noted in ResourceServer?
ResourceServer is used
On Wed, Jul 29, 2009 at 4:31 AM, Ryan Donahue donahu...@gmail.com wrote:
-1 for adding modules by dropping in a jar
Dropping in JAR files that automatically become part of your app is not
going to happen. I've seen too many horror show situations where people
have stuff on their classpath
Glenn,
You have my full attention - this is something I've been sitting on for
quite some time but just not quite sure what the best route forward is.
When im creating these modules, I essentially just build a normal jar
project with maven, and as you say, if I have JS or whatever that I need
http://github.com/dpp/liftweb/commit/0f60807dd64b7fe1430919738b46f2ebe1758f22
...
From: feeder.of.the.be...@gmail.com
Subject:[Lift] Re: ResourceServer problem
Date: July 22, 2009 12:07:14 PM EDT
To: liftweb@googlegroups.com
Reply-To: liftweb@googlegroups.com
On Tue,
Tim,
Here's a thought. GWT uses entry-point class=some fully qualified
class name / to
identify and initialize modules. Perhaps something similar could be
hooked into LiftFilter and an entry point
class identified in web.xml. There should be little objection to xml
configuration, as opposed to
Tim,
My last post may be dismissed as adding more complication than simply
editing Boot.scala. But keep in mind that a consistent, uniform and
robust
procedure for modularization across the Lift universe is to be favored
over the
ad-hoc approach, as exists now. In my view, opening a project and
Hi, Ross,
So, with the changes, where would templates need to be placed in jar
files in
order to be found - or can they be put in any directory as long as the
resource
is noted in ResourceServer?
Glenn...
On Jul 28, 9:39 am, Ross Mellgren dri...@gmail.com wrote:
I've been having a think about this, and are we overlooking something stupid
here? Perhaps OSGi could yield a good solution?
Thoughts?
Cheers, Tim
On 28/07/2009 20:04, glenn gl...@exmbly.com wrote:
Tim,
My last post may be dismissed as adding more complication than simply
editing
If the xml is in the jar file then it would only require the user of the
library to drop thr jar in. It would only be an extra step for the library
author.
The question is whether the extra line saved in Boot is worth the time it takes
for Lift to search the jars whenever you deploy.
It's not related to ResourceServer. Just use the jar-relative path in the embed
tag etc.
-
glenngl...@exmbly.com wrote:
Hi, Ross,
So, with the changes, where would templates need to be placed in jar
files in
order to be found - or can they be put in any
Im just spitballing - I knew Heiko was working on a bunch of modules
and such for Lift so wondered if it was possibly a route forward (im
not really up to speed with OSGi)
Cheers, Tim
On Jul 28, 8:20 pm, glenn gl...@exmbly.com wrote:
My understanding about OSGi is that is allows for dynamic
: Tue, 28 Jul 2009 12:17:44
To: gl...@exmbly.com; liftweb@googlegroups.com
Subject: Re: [Lift] Re: Modularization of Lift code
It's not related to ResourceServer. Just use the jar-relative path in the embed
tag etc.
-
glenngl...@exmbly.com wrote:
Hi, Ross,
So
Hey Naftoli,
Lift has a general aversion to xml configs... Is there another route?
Cheers, Tim
On 28/07/2009 20:47, Naftoli Gugenheim naftoli...@gmail.com wrote:
What I was suggesting is that instead of having to write Lib.init in Boot,
Lift should look in Lib.jar for say /boot.xml which
Classpath management is one of OSGi's features. Another is dynamic
service registry and dependency management. So following that route,
the Lift framework would define an interface that exposes much of what
is currently found in Boot. Modules (OSGi bundles) would create
implementations of that
Hi Glen...
I actually do a lot of this - we have a product at work and i've just
written a bunch of abstractions for work which just require me to do:
MyLib.init
In the boot file of a new application and then everything wires up - I
couldn't think of anything more straightforward?
The vast
39 matches
Mail list logo
