It would be nice if there could be a generalized way of specifying
optionality for fields.(The first though question is whether the default
behavior is consistent -- do all field types equate NULL with their
default?)
I pasted the names of all the field types (by listing all Mapped*.class
files in
I used this command to create my project and was successfully.
mvn archetype:generate -U -DarchetypeGroupId=net.liftweb -
DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=1.1-M6
-DgroupId=demo.helloworld -DartifactId=helloworld2 -
Dversion=1.1-M6
If i use the 1.1-SNAPSHOT, so
Marius-
Thanks for your help on this. I guess I'm not sure how this differs
from the current conception of the If LocParam. As I understand it, it
is checked when determining what to display on the Menu as well as
when a User attempts to access the page (or its subdirectory if
passing a pair).
>From an outsider: Comet/Actors was a big draw for me to Lift. As I learned
more, the view-first philosophy began becoming very helpful.
In addition, it offers an insanely powerful session state API.
It is also secure by default, offering many features that would be a pain to
retrofit into a syste
Ryan,
I have pushed the code to master so give it a couple of hours and
Hudson should automatically start pulling those changes into 1.1-
SNAPSHOT JARs for you. Alternatively do a pull and build locally.
Cheers, Tim
On 10 Oct 2009, at 01:38, Timothy Perrett wrote:
>
> Ryan,
>
> Ignore my l
Guys,
In about a month im speaking at a fairly sizeable event in Belgium and
wanted to ask a few questions about what users see at Lift's unique
value proposition. I did a talk about lift at a bar-camp recently and
whilst they were fairly well received, I think i still assumed too
much informatio
Interesting feature request. Please open a ticket for it at
http://github.com/dpp/liftweb/issues
On Sun, Oct 11, 2009 at 3:06 AM, Eros Candelaresi wrote:
> Hi group,
>
> for a project I am working on interactive forms, i.e. fields
> appear/disappear/enable/disable based on the user input in oth
Yes, a Loc accepts many LocParams ... as I said above If/Unless/Test
would be used in conjunction with CondHidden to also provide
accessibility constraints.
Here is the definition
case object CondHidden(test: () => Boolean) extends LocParam
but we also have case class If(test: () => Boolean, fa
Hi Marius,
Thanks for the response. The LocParam is a good idea, but here is the
attendant problem. No only do I have to hide options A,B,C from user
type 2, I have to make sure user type 2 does not access those pages/
areas. Can I include that in the locParam as well? Right now, I'm
using an
Oh I should have read more carefully. Sorry Marius. Do you think you
could provide an example with dummy's as to how one of these
CondHidden and If's might work in conjunction?
Thanks,
Dave
On Oct 11, 2:54 am, "marius d." wrote:
> So doesn't what I described about help you? ... a conditional
If you want to keep your scripts out of head, you can always use the
element, which supports the same functionality as head
merge - just at the other end of your document :)
the lift:tail element won't appear in the final output, and only its
content will. IIRC, duplicate elements in the "tail"
Hi group,
for a project I am working on interactive forms, i.e. fields
appear/disappear/enable/disable based on the user input in other fields.
Everything is heavily JavaScript event based, so I am currently writing
a small library that simplifies the task of binding JS events and
composing ev
http://udorse.com/about/jobs
udorse is apparently hiring Scala/Lift people. Since one opening
states "Experience with Scala and the Lift framework strongly
preferred", I would think either they're using Lift or they plan to in
the near future.
(I am not affiliated with udorse in any way, just no
13 matches
Mail list logo
