I'm a little late to the game, but my vote would be for keeping all
lift-related attrs under the lift prefix. I don't feel like we need to
attach any meaning the the lift prefix other than that it's something that
lift will use.
Derek
On Thu, Oct 1, 2009 at 9:39 PM, marius d.
Well I said what I had to say. My problem is not really the prefix
name but the existence of other prefixes then lift, that are
interpreted by lift. It's just how I see things now and nothing on
this thread provided sufficient arguments to convince me
otherwise ...
not much else for me to do if
Marius,
I have a ton of respect for your opinion and I appreciate your analysis.
I have been following this thread and thinking, what does the lift: prefix
mean? In my mind, it means this thing will be changed based on evaluating
some code. So, using the lift: prefix for something that also
David,
Thank you very much for your kind words. Personally I don't see any
reason why the lift prefix can not also have the semantic for
enriching the context you described this thing will be changed based
on evaluating some code.. These are after all attributes and
attributes to me are about
Have we been misunderstanding each other? The lift prefix can be a snippet
invocation as an attribute too. Thus the fact that it's an attribute does not
separate reserved names from user space snippet names.
-
marius d.marius.dan...@gmail.com wrote:
David,
On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
I thought there were issues here because anything starting lift: gets
executed as a snippet.
Correct BUT lift:par or lift:parallel attributes are also applicable
to snippets context. They determine the snippet's execution
Could you elaborate on why adding a new prefix may not be a good idea? And is
it better or worse than having it unprefixed?
-
marius d.marius.dan...@gmail.com wrote:
On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
I thought there
It has been debated many times in slightly different contexts. To me
it is more about clarity. We add a new prefix now, tomorrow add
another one and so on. People would have to remember what goes where
and mix things up. To me lift prefix is enough and quite clear. It is
more than just s snippet
I think everyone agrees in concept, that an arbitrary prefix sets a bad
precendent, which is why it is no longer do:par. But on the other hand, if the
part after lift: is either a reserved word or a user word--a snippet
name--then the more reserved words, the more you limit snippet names.
I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so.
So what is your proposal? Am I interpreting you correctly that you are for a
prefix of 'lift'? And it will be a reserved suffix?
-
marius d.marius.dan...@gmail.com wrote:
I realize that I may be a little late here but I do have second
thoughts about liftx
lift is already a reserved prefix for snippets. So I'd stay with
simply lift prefix for these attributes as well.
Br's,
Marius
On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
So what is your proposal? Am I interpreting you correctly that you are for a
prefix of 'lift'? And
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:
If you like the idea of having them all as attributes but don't like the
idea of using a single attribute ('xx:eager_eval=true xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is the
Looks great :-) can't wait to see this in master.
Cheers, Tim
Sent from my iPhone
On 25 Sep 2009, at 18:02, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
If you like the idea of having them all as
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:
What do you mean by as a normal snippet?
The parallel snippet processing is implemented deep inside LiftSession.
It's not a snippet. All the lift:xxx/ tags, even those with defaults
built into Lift, are
My 2 cents,
I'm not sure I'm a fan of do: namespace, though I agree it would be
nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?
-Ross
On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
If you like the idea of having them all as attributes but don't like the idea
of using a single attribute ('xx:eager_eval=true xx:parallel=true' rather
than 'xx:eval=eager parallel' as I suggested, where xx is the prefix to be
chosen) then maybe the prefix should be 'eval'.
As far as ajax
David Pollak feeder.of.the.be...@gmail.com writes:
I've added code (it's in review board right now) that will automatically
farm any snippet with the do:lazy='true' attribute set.
So, lift:foo/ will execute the foo snippet inline.
lift:foo do:lazy=true/ will execute the foo snippet in
Could that be changed to lift:concurrent or lift:par etc. (see email on
scala-user from Marting Odersky mentioned the future use of 'seq' and 'par' in
concurrent collections)?
Why use a different prefix than everything else built in to lift? And 'lazy' is
arguably not what's happening.
Thanks.
+1
I think naftoli's suggestion is a good one and we should go with
something that carries a better semantic.
Cheers, Tim
On Sep 23, 11:59 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Could that be changed to lift:concurrent or lift:par etc. (see email on
scala-user from Marting
On Tue, Sep 22, 2009 at 11:52 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:
David Pollak feeder.of.the.be...@gmail.com writes:
I've added code (it's in review board right now) that will automatically
farm any snippet with the do:lazy='true' attribute set.
So, lift:foo/ will execute
On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Could that be changed to lift:concurrent or lift:par etc. (see email on
scala-user from Marting Odersky mentioned the future use of 'seq' and 'par'
in concurrent collections)?
Why use a different prefix than
A snippet attribute can be invoked with something other than
lift:snippet=Class.method? There's a short syntax? What is it?
What was used for the feature that inserts a snippet asynchronously via Ajax?
My concern is that as more features are thought up and added they shouldn't all
end up with
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:
A snippet attribute can be invoked with something other than
lift:snippet=Class.method? There's a short syntax? What is it?
There may be a short syntax (e.g., lift:Class.method) in the future.
What was used for
What do you mean by as a normal snippet? That you will nest your snippet
inside a special snippet?
To me it seems worthwhile to have a consistency between the two syntax-wise,
since they have some common denominator semantics-wise.
Actually, maybe throw in eager_eval to the mix. Maybe we could
I've added code (it's in review board right now) that will automatically
farm any snippet with the do:lazy='true' attribute set.
So, lift:foo/ will execute the foo snippet inline.
lift:foo do:lazy=true/ will execute the foo snippet in parallel and join
the result back to page before its
Lift only uses event-based Actors for supporting CometActors. All parts of
the standard HTTP request/response cycle (except for the CometActors) are
handled on a single thread.
Having a single thread handle an HTTP request is not materially less
efficient in terms of multi-core CPU utilization
On Sep 21, 2:33 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Lift only uses event-based Actors for supporting CometActors. All parts of
the standard HTTP request/response cycle (except for the CometActors) are
handled on a single thread.
Hi David -
Thanks for your quick response.
On Mon, Sep 21, 2009 at 1:19 PM, espeed james.thorn...@gmail.com wrote:
On Sep 21, 2:33 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Lift only uses event-based Actors for supporting CometActors. All parts
of
the standard HTTP request/response cycle (except for the CometActors)
On Sep 21, 4:29 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Well.. there's a Java way of doing exactly that: fork/join on a thread.
Seehttp://java.sun.com/javase/6/docs/api/java/lang/Thread.html
But to weave this into the page rendering, there would be some work required
on your
On Mon, Sep 21, 2009 at 3:19 PM, espeed james.thorn...@gmail.com wrote:
On Sep 21, 4:29 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Well.. there's a Java way of doing exactly that: fork/join on a thread.
Seehttp://java.sun.com/javase/6/docs/api/java/lang/Thread.html
But to
31 matches
Mail list logo
