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. wrote:
>
> David,
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. wrote:
David,
Thank you very muc
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
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
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 m
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. (
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
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. wrote:
On Sep 30, 8:23 am, Kevin Wright
wrote:
> I thought there were issues here because anything starting lift: gets
>
On Sep 30, 8:23 am, Kevin Wright
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 semantics.
So I'm still quest
I thought there were issues here because anything starting lift: gets
executed as a snippet.
I'm still for an eval: prefix, as these proposals all relate to how a
page is evaluated.
On Wed, Sep 30, 2009 at 5:34 AM, marius d. wrote:
>
> lift is already a "reserved" prefix for snippets. So I'd
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 wrote:
> So what is your proposal? Am I interpreting you correctly that you are for a
> prefix of 'lift'? And it will be a res
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. wrote:
I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a b
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. Historica
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
wrote:
>
>
> On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim > wrote:
>
> If you like the idea of having them all as attributes but don't like
> the idea of using a
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 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
Can I recommend "eval" as a prefix...That then gives us eval:eager="true"
and eval:parallel="true"
On Thu, Sep 24, 2009 at 7:33 PM, Naftoli Gugenheim 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:pa
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 "aj
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 > wrote:
>
> What do you me
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim wrote:
>
> 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 tags, even those with defaults
built into Lift, are implemented as snippets and are invo
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
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim wrote:
>
> 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 the feature t
That's yet more sensible talking... +1
Btw, are there any issues with using undefined attribute namespaces?
Or is that just for elements?
Cheers, Tim
Sent from my iPhone
On 23 Sep 2009, at 18:40, Naftoli Gugenheim
wrote:
>
> A snippet attribute can be invoked with something other 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 3:59 AM, Naftoli Gugenheim wrote:
>
> 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
On Tue, Sep 22, 2009 at 11:52 PM, Jeppe Nejsum Madsen wrote:
>
> David Pollak 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, will execute the foo snippet inline.
> >
> > will execut
+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 wrote:
> Could that be changed to lift:concurrent or lift:par etc. (see email on
> scala-user from Marting Odersky mentioned the fut
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.
David Pollak 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, will execute the foo snippet inline.
>
> will execute the foo snippet in parallel and join
> the result back to page before its re
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, will execute the foo snippet inline.
will execute the foo snippet in parallel and join
the result back to page before its rendered.
This should allow for the u
There's a difference between some experimental stuff and the robust stuff
that one can build robust web apps on. I've got my finger in a fair number
of the projects that you mention and I don't think (with the exception of
Robey's stuff which I haven't played with a lot) I would trust my app to
th
On Sep 21, 5:30 pm, David Pollak
wrote:
> Threads are used in Scala actors, but only while processing a message (actor
> jobs are allocated to threads in a thread pool). In the case of asking your
> external ad server for information, Scala Actors are not going to help you
> because they have no
On Mon, Sep 21, 2009 at 3:19 PM, espeed wrote:
>
> On Sep 21, 4:29 pm, David Pollak
> 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 woul
On Sep 21, 4:29 pm, David Pollak
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 part: forking the threads
On Mon, Sep 21, 2009 at 1:19 PM, espeed wrote:
>
> On Sep 21, 2:33 pm, David Pollak
> 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 Davi
On Sep 21, 2:33 pm, David Pollak
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. If an app developer wants to
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 tha
36 matches
Mail list logo
