[Lift] Re: error message tag
I copied and pasted the error message code into my own error message
utility and then changed the blank output to Text(""). I also wanted to
rewrite other parts of it.
It seems there is always a trade-off between convenience and
configuration. My coding style is very different from David's (at least
where HTML is concerned), so I find myself rewriting (modifying, really)
lots of stuff to make it work the way I need it to. But it sure saves
time to have a base of code to modify, rather than having to write it
all from scratch.
Chas.
Oliver wrote:
> I have the following to output an error message against
>
>
> When I have an error its all fine, but when I don't have an error I
> get the following html
>
>
> Is there any way of getting rid of the empty span?
>
> cheers
> Oliver
>
> >
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] context path
I have a few links within my pages where I don't want lift to prepend the context path to the url. Is there any way to do this? cheers Oliver --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] error message tag
I have the following to output an error message against When I have an error its all fine, but when I don't have an error I get the following html Is there any way of getting rid of the empty span? cheers Oliver --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
That may be workable but I have to recoil a little when we talk about
bringing Spring into the mix. It has its purpose but I would hate to make it
an implicit requirement of using Record with JPA; it's just huge.
Derek
On Mon, Dec 15, 2008 at 12:46 PM, Daniel Mueller
wrote:
>
> I never did it with JPA, that's why I mentioned that there might be
> some problems to circumnavigate (my websearch turned up that it's not
> possible, but I might have missed something). But on the actual
> backend frameworks you can do things like that (or at least hibernate
> can [1,2, also see 3 below]).
>
> The best resource to describe what we want to do is Spring ORM [3].
> They had the same problem and describe the caveats with it (see the
> text box for loadtime weaving under the JPA section). If we would run
> our generation through Spring ORM we should probably get away with a
> Record-only setup, where Record boots Spring ORM with dynamic classes
> (Maps) and configures the desired backend. The nice thing would be
> that Spring is already aware of which backend you use and optimizes
> accordingly.
>
> I don't really like the fact that this adds a truckload of
> dependencies to the stack (spring-{orm,beans,context,core,tx} are
> required, couple more optional), but it's the easiest solution I can
> think of in terms of integration and timerequirements, and it should
> also be pretty stable and straightforward to use for the users (Spring
> has nice documentation IMO). Oh, and just if you were wondering, this
> is the supported frameworks list: Hibernate, JDO, Oracle TopLink,
> iBATIS SQL Maps and JPA. The biggies are supported without even going
> through JPA. Sweet.
>
> Daniel
>
> [1] http://forums.oracle.com/forums/message.jspa?messageID=2432779
> [2] http://wiki.eclipse.org/Eclipselink/Examples/JPA/Dynamic
> [3] http://static.springframework.org/spring/docs/2.5.x/reference/orm.html
>
> On Dec 15, 9:41 pm, "Derek Chen-Becker" wrote:
> > I've been thinking a little about the XML path and there may be a
> wrinkle.
> > No matter how you define the XML mappings, JPA expects persistable fields
> to
> > either be real fields (var) on the instance or getter/setter pairs; using
> an
> > object for field a la Record still isn't either of these. I have a busy
> few
> > weeks ahead but I'm going to do some reading in the meantime and see if
> we
> > can come up with something transparent but easy to use.
> >
> > Derek
> >
> > On Mon, Dec 15, 2008 at 12:39 AM, Daniel Mueller
> > wrote:
> >
> >
> >
> > > (Reactivating discussion. I guess it's been discussed more on the
> > > committer list, but here you have my 2 cents anyway)
> >
> > > For the sake of the Record-JPA discussion, people will fall into two
> > > categories when they are using lift:
> > > * The first group of people have an existing, working, tested JPA/OR
> > > based data access library written in Java and are looking to integrate
> > > that with a webapp written in lift. They will usually be coming from
> > > an enterprise background, and will have some constraints on what they
> > > can develop from scratch ("no - we will not rewrite all the db access
> > > code to support the new web framework").
> > > * The second group doesn't have an existing data access library in
> > > Java and would like to write all their new stuff with lift in Scala.
> > > But maybe they have mapping/usage requirements that precludes using
> > > mapper because it's too simple, or they just know their way around one
> > > of the other JPA enabled OR libs and want to bank on that knowledge
> > > (without writing the entire layer in Java).
> > > * The third group also doesn't have an existing data access library,
> > > but for some reasons, they want their OR model not only be accessible
> > > from lift, but actually also from Java code. This means that they not
> > > only have to be able use JPA, but that the Scala code they write has
> > > to be _JPA compatible_ (Java usable JPA entities etc.).
> >
> > > For the first group, some sort of delegation strategy from the Record
> > > entity to the JPA entity is necessary (unless you can mixin the record
> > > stuff on top of an actual JPA entity?). The JPA/OR configuration is
> > > already in place on the existing lib (annotations/xml). The only thing
> > > that record is doing is adding another layer on top of it for
> > > validation, binding to UI, maybe querying. Something like what was
> > > proposed earlier by Derek should be enough
> >
> > > > class MyEntry extends Record[MyEntry] {
> > > > var inner : RealEntry = _
> >
> > > > object name extends StringField(this) with Delegation
> > > > name.delegate(inner.name, inner.name = _)
> >
> > > > ...
> > > > }
> >
> > > Now for the second group, they probably would like to have all the
> > > power associated with a JPA/OR framework without resolving to writing
> > > that layer in Java. Mind you that this is quite a different problem
> > > from what the first group wants to solve.
> >
[Lift] Re: Comment on net.liftweb.sitemap.Loc.Title
Thanks, I missed the title(ParamType) method where it defaults to the link
text.
Derek
On Mon, Dec 15, 2008 at 11:46 AM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:
> Derek,
>
> If you can get to the page (it has a valid parameter), then the title
> calculation will default to using linkText and you'll get what you want.
>
> Put another way, there should be no case where the title of the page is the
> page's name.
>
> Thanks,
>
> David
>
>
> On Sun, Dec 14, 2008 at 6:52 AM, Derek Chen-Becker
> wrote:
>
>> I'm doing our SiteMap chapter right now and it strikes me as a little odd
>> that the default Title for a Loc is the name of the Loc instead of the Loc
>> text. That means that if I do something like:
>>
>> def userMenuText = User.name + "'s profile"
>> val userMenu = Menu(Loc("usermenu", "user" :: "profile" :: Nil,
>> userMenuText))
>>
>> then the default title of the page is going to be "usermenu", if I'm
>> reading the code correctly. It just seems redundant to have to provide a
>> custom Title as well as custom Link text, even if technically they could use
>> the same underlying code for text calculation.
>>
>> Cheers,
>>
>> Derek
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: The first Lift tutorial: a ToDo application
On Mon, Dec 8, 2008 at 10:27 AM, Dano wrote: > > David, > > Since I am really interested in view/logic separation, I focused on > sections 1.5 and 1.6. My overall feedback is that I really like > starting with the example and following up with the philosophy. Also, > you accomplished the goal of telling the reader how the separation is > accomplished as well as where the 'guard rails' are to enforcing a > proper separation. Finally, having attended the lift workshop and > trying to puzzle thru the ToDo example afterwards, I am thankful for > this document so that I can gain a proper understanding of what is > going on. > > In section 1.5, you describe the snippet lookup mechanism. There is a > sentence which I don't understand: > > Lift will convert underscore separated names to > CamelCase names when it looks up classes. > > I am having trouble understanding which underscores you are referring > to. > > > In section 1.6 there is a code snippet which looks like: > > 2007 > Dan, Good suggestion. I'm about to commit up code that will allow you to do: The tag that is bound to will have its id attribute set to "FruitBat" and its class attribute set to "myFruit" Thanks, David > > The year snippet replaces the above with a > generated from the snippet code. If I want the HTML designer to be > able to style the above select with css code, what is the guideline? > Should the select above have a class attribute? Also, if I want my > view to be testable, should I include an id attribute as well? > > I really enjoyed the example and will dive in further as time permits. > > Thanks. > > > Dano > > > > > On Dec 5, 5:09 pm, "David Pollak" > wrote: > > Folks, > > > > I've got a first draft of the first Lift tutorial: a ToDo application. > > > > The application demonstrates creating a new Lift project, creating a > model, > > linking the view to logic, adding validation and form input to the model, > > creating forms, and doing Ajax calls. > > > > I'm enclosing the PDF of the tutorial along with the resulting > application. > > > > Please let me know if you've got feedback on it. > > > > Thanks, > > > > David > > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Collaborative Task Managementhttp://much4.us > > Follow me:http://twitter.com/dpp > > Git some:http://github.com/dpp > > > > todo_steps.pdf > > 206KViewDownload > > > > todo.tgz > > 9KViewDownload > > > -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: The first Lift tutorial: a ToDo application
Changed On Fri, Dec 5, 2008 at 6:42 PM, Kris Nuttycombe wrote: > Also, for consistency: > > > > > David > Pollak > > > > > => > > > > > David > Pollak > > > > > > On Fri, Dec 5, 2008 at 7:36 PM, Kris Nuttycombe > wrote: > >> Very nice! On the minor typo front: >> >> >> Please Log In Dude >> >> >> Should be >> >> >> Please Log In Dude >> >> >> Kris >> >> >> On Fri, Dec 5, 2008 at 7:18 PM, TylerWeir wrote: >> >>> >>> Looks good Dave, good clear explanations. >>> >>> 2 suggestions: >>> 1. >>> 1.13 Display and Editting to do items --> >>> 1.13 Display and Editing to do items >>> >>> 2. >>> You may want to toss in a few screenshots of the app. >>> >>> Ty >>> >>> On Dec 5, 8:09 pm, "David Pollak" >>> wrote: >>> > Folks, >>> > >>> > I've got a first draft of the first Lift tutorial: a ToDo application. >>> > >>> > The application demonstrates creating a new Lift project, creating a >>> model, >>> > linking the view to logic, adding validation and form input to the >>> model, >>> > creating forms, and doing Ajax calls. >>> > >>> > I'm enclosing the PDF of the tutorial along with the resulting >>> application. >>> > >>> > Please let me know if you've got feedback on it. >>> > >>> > Thanks, >>> > >>> > David >>> > >>> > -- >>> > Lift, the simply functional web frameworkhttp://liftweb.net >>> > Collaborative Task Managementhttp://much4.us >>> > Follow me:http://twitter.com/dpp >>> > Git some:http://github.com/dpp >>> > >>> > todo_steps.pdf >>> > 206KViewDownload >>> > >>> > todo.tgz >>> > 9KViewDownload >>> >>> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: The first Lift tutorial: a ToDo application
Fixed. On Fri, Dec 5, 2008 at 6:36 PM, Kris Nuttycombe wrote: > Very nice! On the minor typo front: > > > Please Log In Dude > > > Should be > > > Please Log In Dude > > > Kris > > > On Fri, Dec 5, 2008 at 7:18 PM, TylerWeir wrote: > >> >> Looks good Dave, good clear explanations. >> >> 2 suggestions: >> 1. >> 1.13 Display and Editting to do items --> >> 1.13 Display and Editing to do items >> >> 2. >> You may want to toss in a few screenshots of the app. >> >> Ty >> >> On Dec 5, 8:09 pm, "David Pollak" >> wrote: >> > Folks, >> > >> > I've got a first draft of the first Lift tutorial: a ToDo application. >> > >> > The application demonstrates creating a new Lift project, creating a >> model, >> > linking the view to logic, adding validation and form input to the >> model, >> > creating forms, and doing Ajax calls. >> > >> > I'm enclosing the PDF of the tutorial along with the resulting >> application. >> > >> > Please let me know if you've got feedback on it. >> > >> > Thanks, >> > >> > David >> > >> > -- >> > Lift, the simply functional web frameworkhttp://liftweb.net >> > Collaborative Task Managementhttp://much4.us >> > Follow me:http://twitter.com/dpp >> > Git some:http://github.com/dpp >> > >> > todo_steps.pdf >> > 206KViewDownload >> > >> > todo.tgz >> > 9KViewDownload >> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: JPA and Record
I never did it with JPA, that's why I mentioned that there might be
some problems to circumnavigate (my websearch turned up that it's not
possible, but I might have missed something). But on the actual
backend frameworks you can do things like that (or at least hibernate
can [1,2, also see 3 below]).
The best resource to describe what we want to do is Spring ORM [3].
They had the same problem and describe the caveats with it (see the
text box for loadtime weaving under the JPA section). If we would run
our generation through Spring ORM we should probably get away with a
Record-only setup, where Record boots Spring ORM with dynamic classes
(Maps) and configures the desired backend. The nice thing would be
that Spring is already aware of which backend you use and optimizes
accordingly.
I don't really like the fact that this adds a truckload of
dependencies to the stack (spring-{orm,beans,context,core,tx} are
required, couple more optional), but it's the easiest solution I can
think of in terms of integration and timerequirements, and it should
also be pretty stable and straightforward to use for the users (Spring
has nice documentation IMO). Oh, and just if you were wondering, this
is the supported frameworks list: Hibernate, JDO, Oracle TopLink,
iBATIS SQL Maps and JPA. The biggies are supported without even going
through JPA. Sweet.
Daniel
[1] http://forums.oracle.com/forums/message.jspa?messageID=2432779
[2] http://wiki.eclipse.org/Eclipselink/Examples/JPA/Dynamic
[3] http://static.springframework.org/spring/docs/2.5.x/reference/orm.html
On Dec 15, 9:41 pm, "Derek Chen-Becker" wrote:
> I've been thinking a little about the XML path and there may be a wrinkle.
> No matter how you define the XML mappings, JPA expects persistable fields to
> either be real fields (var) on the instance or getter/setter pairs; using an
> object for field a la Record still isn't either of these. I have a busy few
> weeks ahead but I'm going to do some reading in the meantime and see if we
> can come up with something transparent but easy to use.
>
> Derek
>
> On Mon, Dec 15, 2008 at 12:39 AM, Daniel Mueller
> wrote:
>
>
>
> > (Reactivating discussion. I guess it's been discussed more on the
> > committer list, but here you have my 2 cents anyway)
>
> > For the sake of the Record-JPA discussion, people will fall into two
> > categories when they are using lift:
> > * The first group of people have an existing, working, tested JPA/OR
> > based data access library written in Java and are looking to integrate
> > that with a webapp written in lift. They will usually be coming from
> > an enterprise background, and will have some constraints on what they
> > can develop from scratch ("no - we will not rewrite all the db access
> > code to support the new web framework").
> > * The second group doesn't have an existing data access library in
> > Java and would like to write all their new stuff with lift in Scala.
> > But maybe they have mapping/usage requirements that precludes using
> > mapper because it's too simple, or they just know their way around one
> > of the other JPA enabled OR libs and want to bank on that knowledge
> > (without writing the entire layer in Java).
> > * The third group also doesn't have an existing data access library,
> > but for some reasons, they want their OR model not only be accessible
> > from lift, but actually also from Java code. This means that they not
> > only have to be able use JPA, but that the Scala code they write has
> > to be _JPA compatible_ (Java usable JPA entities etc.).
>
> > For the first group, some sort of delegation strategy from the Record
> > entity to the JPA entity is necessary (unless you can mixin the record
> > stuff on top of an actual JPA entity?). The JPA/OR configuration is
> > already in place on the existing lib (annotations/xml). The only thing
> > that record is doing is adding another layer on top of it for
> > validation, binding to UI, maybe querying. Something like what was
> > proposed earlier by Derek should be enough
>
> > > class MyEntry extends Record[MyEntry] {
> > > var inner : RealEntry = _
>
> > > object name extends StringField(this) with Delegation
> > > name.delegate(inner.name, inner.name = _)
>
> > > ...
> > > }
>
> > Now for the second group, they probably would like to have all the
> > power associated with a JPA/OR framework without resolving to writing
> > that layer in Java. Mind you that this is quite a different problem
> > from what the first group wants to solve.
> > * They just want to have Record entities, no separate JPA entity, no
> > delegation.
> > * They don't want to duplicate configuration from what they already
> > specify on Record entities.
> > * Have the integration as hassle free as possible, because in their
> > eyes, there is no actual delegation.
>
> > What the second group needs is a bit trickier, and most of the
> > discussion has revolved around how to make it as transparent as
> > possible (compiler p
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius wrote: > Sorry Dan ... There were too many changes in LiftRules. You should be > able to determine real quick what changed in LiftRules since the > variables naming is more or less the same. > > If you can not fix your code can you please copy-paste it here ? ... > in this way I may be able to help. > > Br's, > Marius > > On Dec 15, 1:55 am, Dano wrote: > > > Marius, > > > Is there someway you can communicate what the 'from' and 'to' changes > > are so that I can have a chance at being able to fix my now broken > > code? > > > Dan > > > On Dec 13, 12:31 pm, Marius wrote: > > > > All, > > > > I committed a bunch of changes inLiftRules. In a previous thread > > > Jorge suggested the abstraction ofLiftRulesvariables. Lists of > > > functions are now abstracted by RulesSeq trait, which contains prepend > > > and append functions. Note that if you're calling prepend/append > > > functions after boot they will throw an exception. If there are > > > compelling reasons not to do this please let us know. This is just a > > > mechanism to enforce the use of these functions on startup. > > > > Br's, > > > Marius --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Comment on net.liftweb.sitemap.Loc.Title
Derek,
If you can get to the page (it has a valid parameter), then the title
calculation will default to using linkText and you'll get what you want.
Put another way, there should be no case where the title of the page is the
page's name.
Thanks,
David
On Sun, Dec 14, 2008 at 6:52 AM, Derek Chen-Becker wrote:
> I'm doing our SiteMap chapter right now and it strikes me as a little odd
> that the default Title for a Loc is the name of the Loc instead of the Loc
> text. That means that if I do something like:
>
> def userMenuText = User.name + "'s profile"
> val userMenu = Menu(Loc("usermenu", "user" :: "profile" :: Nil,
> userMenuText))
>
> then the default title of the page is going to be "usermenu", if I'm
> reading the code correctly. It just seems redundant to have to provide a
> custom Title as well as custom Link text, even if technically they could use
> the same underlying code for text calculation.
>
> Cheers,
>
> Derek
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: Binding Problem - Help
On Sun, Dec 14, 2008 at 9:39 PM, Oliver wrote:
>
> Thanks for all the help, it appears to all be working now - I had a
> feeling I was going to be fed to the lions, wolves, tigers and bears
> if I didn't find a fix, and quick.
>
> One question, does the name generation have to be based on a random
> number generator?
It was based on System.nanoTime and a random number. Lift needs increasing
numbers for field names in order to sort the incoming fields and process
them in the proper order. It seems that nanoTime was not changing between
field creation calls, so I changed the mechanism to use a global serial
number (monotonically increasing) that is initialized at a random point.
This guarantees in-order execution of the functions and there's no
possibility of collision and the random component makes replay attacks that
much more difficult.
> I realize, with the length of the number I probably
> won't see the same error in the life of the universe, but you never
> know your luck.
>
> On Mon, Dec 15, 2008 at 12:36 PM, David Pollak
> wrote:
> >
> >
> > On Sun, Dec 14, 2008 at 5:06 PM, Oliver wrote:
> >>
> >> David
> >>
> >> Thanks for the prompt reply.
> >>
> >> I'll upgrade to the latest version of lift so I can use the fix when
> >> it comes in. Is everything relatively stable at the current snapshot?
> >
> > I've pushed the change. Give it an hour or so to get built in Maven.
> > The APIs are changing right now, but the code itself is stable (the APIs
> > changes have not introduced defects.)
> > Thanks,
> > David
> >
> >>
> >> cheers
> >> Oliver
> >>
> >> On Mon, Dec 15, 2008 at 11:47 AM, David Pollak
> >> wrote:
> >> > Okay,
> >> > The problem is that your computer is too fast. :-)
> >> > Lift assigns function names based on the nano time. It turns out that
> >> > the
> >> > methods are getting called so fast, there's no nano tick and the order
> >> > of
> >> > the function creation is not reflected in the function name.
> >> > I've got a fix. I'll roll it into Lift tonight or tomorrow.
> >> > Thanks,
> >> > David
> >> >
> >> > On Sun, Dec 14, 2008 at 3:44 PM, Oliver wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Its Ubuntu Gutsy running a virtual vsx.
> >> >> The processor is a dual cpu 2.8
> >> >> Theres 2GB of memory, but Apache tomcat has 500MB.
> >> >>
> >> >> I'm running on a snapshot of lift webkit frozen at
> >> >> 0.10-20080930.234135-129
> >> >>
> >> >> I'll send the html in a moment.
> >> >> Cheers
> >> >> Oliver
> >> >>
> >> >> On Mon, Dec 15, 2008 at 10:28 AM, David Pollak
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Sun, Dec 14, 2008 at 3:17 PM, Oliver wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> I've got a error on one of our Apache/Tomcat servers with binding,
> >> >> >> it
> >> >> >> works in Jetty and another Apache/Tomcat server.
> >> >> >>
> >> >> >> It looks like lift is calling some of the function setters after
> >> >> >> calling a method on a StatefullSnippet. For example,
> >> >> >> in the example below, v => who(Full(v)) would be getting called
> >> >> >> after
> >> >> >> doProcess() is called
> >> >> >>bind("hello", xhtml, "whoField" -->
> text(who.openOr(""),
> >> >> >> v
> >> >> >> => who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
> >> >> >> doProcess() ) )
> >> >> >>
> >> >> >> Has anyone got any idea what might be going on?
> >> >> >
> >> >> > What kind of machine is the problem happening on (OS, processor,
> >> >> > speed,
> >> >> > number of processors)?
> >> >> > Can you send me the static HTML generated by a page that's causing
> >> >> > the
> >> >> > problem?
> >> >> > Thanks,
> >> >> > David
> >> >> >
> >> >> >>
> >> >> >> cheers
> >> >> >> Oliver
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Lift, the simply functional web framework http://liftweb.net
> >> >> > Collaborative Task Management http://much4.us
> >> >> > Follow me: http://twitter.com/dpp
> >> >> > Git some: http://github.com/dpp
> >> >> >
> >> >> > >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Lift, the simply functional web framework http://liftweb.net
> >> > Collaborative Task Management http://much4.us
> >> > Follow me: http://twitter.com/dpp
> >> > Git some: http://github.com/dpp
> >> >
> >> > >
> >> >
> >>
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Collaborative Task Management http://much4.us
> > Follow me: http://twitter.com/dpp
> > Git some: http://github.com/dpp
> >
> > >
> >
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
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 o
[Lift] Re: Working CRUD based on "To Do" tutorial
On Sun, Dec 14, 2008 at 5:58 PM, Stefan Scott wrote:
>
> OK, I've gotten through the tutorial (page 23).
>
> I was doing a bit of testing - I tried putting a string of length 2
> into field 'desc' (which is supposed to be at least 3 characters
> long), and I didn't get an error message.
That's weird.
>
>
> Too tired now to check to see if the validation code for 'desc' is
> actually getting called - will look later.
>
>
> I also added another field ('location', varchar(63)) which accepts
> null values
I would strongly advise against allowing null values to float around in your
code. There are plenty of ways to avoid nulls in Scala code (Option/Can)
and Lift does not do null checking because of this.
> , and used rather than so as to display rows
> with aligned columns. While clicking around some more I noticed that
> if the record has been saved and the 'location' field is null there's
> nothing to click on to make it "swap" from a displayed field to an
> editable field - in case you wanted to enter a 'location' later.
>
>
> Next I'll probably want to poke around and see what lines I have to
> change to try it with H2 instead of Derby.
>
>
> All in all, very exciting to have a working Ajaxified CRUD web-db in
> so few lines of code in a compiled, type-safe language.
>
>
> - Stefan Scott
>
>
>
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] *Breaking Change* (minor)
Folks, I've gotten rid of the CometActor singleon (object) and its next method. If you need a serial number, please use Helpers.nextNum Thanks, David -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.
The scala-tools.org server were off part of sunday.
Sorry for interruption.
On Mon, Dec 15, 2008 at 02:09, mike beckerle wrote:
>
> Certainly there is nothing blocking java in any way.
>
> However, just trying again, this time it is working better. Somebody
> has fixed something on the server end I'm sure. I'm doing the exact
> same thing, but it seems to be able to communicate properly with the
> associated servers..
>
> However, mvn jetty:run -U still fails
>
> Downloading:
> http://scala-tools.org/repo-snapshots/net/liftweb/lift-widgets/0.10-SNAPSHOT/lift-widgets-0.10-SNAPSHOT.jar
> 243K downloaded
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [scala:compile {execution: default}]
> [INFO] suggestion: remove the scalaVersion from pom.xml
> [ERROR] /home/mbeckerle/todo/src/main/scala
> [INFO] Compiling 3 source files to /home/mbeckerle/todo/target/classes
> Downloading:
> http://scala-tools.org/repo-releases/org/scala-lang/scala-compiler/2.7.2/scala-compiler-2.7.2.jar
> 6083K downloaded
> [WARNING] /home/mbeckerle/todo/src/main/scala/bootstrap/liftweb/
> Boot.scala:42: error: value appendEarly is not a member of object
> net.liftweb.http.LiftRules
> [WARNING] LiftRules.appendEarly(makeUtf8)
> [WARNING] ^
> [WARNING] one error found
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO] --
>
>
> On Dec 14, 2:11 pm, Josh Suereth wrote:
>> Is your firewall blocking java? This would cause maven to be unable
>> to download dependencies.
>>
>> Sent from my iPhone
>>
>> On Dec 14, 2008, at 1:13 PM, mike beckerle wrote:
>>
>>
>>
>> > I can browse to the location just fine. There is no proxy or other
>> > wierdness between me and the internet. Just the usual home firewall
>> > (NAT) device.
>>
>> > On Dec 13, 1:45 pm, "David Pollak"
>> > wrote:
>> >> On Sat, Dec 13, 2008 at 10:34 AM, mike beckerle
>> >> wrote:
>>
>> >>> This did not work. Still failed.
>>
>> >>> There are disturbing messages in here about blacklisting sites due
>> >>> to
>> >>> errors and such.
>>
>> >>> becke...@ubuntu810desktop:~/todo$ mvn jetty:run -U
>> >>> [INFO] Scanning for projects...
>> >>> [INFO] Searching repository for plugin with prefix: 'jetty'.
>> >>> [INFO] org.apache.maven.plugins: checking for updates from scala-
>> >>> tools.org
>> >>> [WARNING] repository metadata for: 'org.apache.maven.plugins' could
>> >>> not be retrieved from repository: scala-tools.org due to an error:
>> >>> Error transferring file
>> >>> [INFO] Repository 'scala-tools.org' will be blacklisted
>>
>> >> This is the problem. For some reason, you're not able to connect to
>> >> scala-tools.org.
>>
>> >> Are you behind an HTTP proxy?
>>
>> >> Does the proxy have whitelist/blacklist of sites and/or IP addresses?
>>
>> >> Can you browse tohttp://scala-tools.org/repo-snapshots/net/liftweb/
>> >> with
>> >> your web browser?
>>
>> >>> [INFO] org.apache.maven.plugins: checking for updates from central
>> >>> [INFO] org.codehaus.mojo: checking for updates from central
>> >>> [INFO] artifact org.scala-tools:maven-scala-plugin: checking for
>> >>> updates from central
>> >>> [INFO]
>> >>> ---
>> >>> ---
>> >>> --
>> >>> [ERROR] BUILD ERROR
>> >>> [INFO]
>> >>> ---
>> >>> ---
>> >>> --
>> >>> [INFO] The plugin 'org.scala-tools:maven-scala-plugin' does not
>> >>> exist
>> >>> or no valid version could be found
>> >>> [INFO]
>> >>> ---
>> >>> ---
>> >>> --
>> >>> [INFO] For more information, run Maven with the -e switch
>> >>> [INFO]
>> >>> ---
>> >>> ---
>> >>> --
>> >>> [INFO] Total time: 26 seconds
>> >>> [INFO] Finished at: Sat Dec 13 13:29:24 EST 2008
>> >>> [INFO] Final Memory: 1M/4M
>> >>> [INFO]
>> >>> ---
>> >>> ---
>> >>> --
>> >>> mbecke...@ubuntu810desktop:~/todo$
>>
>> >>> On Dec 11, 7:57 am, "David Bernard"
>> >>> wrote:
>> The first time you run jetty :
>>
>> mvn jetty:run -U
>>
>> I learn a way to avoid this problem (for futur archetype, I'll
>> try it
>> next week-end)
>>
>> /davidB
>>
>> On Thu, Dec 11, 2008 at 13:31, Josh Suereth
>>
>> >>> wrote:
>> > Thanks, and sorry for the typos.
>>
>> > What you want (in either your ~/.m2/settings.xml or
>> >>> ${project.dir}/pom.xml)
>> > is the following:
>>
>> >
>> >
>> > scala-tools.org
>>
>> > Scala-tools Maven2 Repository
>> > http://scala-tools.org/repo-releases
>> >
>> >
>>
>> > snapshots.scala-tools.org
>> > Scala-tools Maven2 Snapshot Repository
>> > http://scala-tools.org/repo-sna
[Lift] Re: JPA and Record
I've been thinking a little about the XML path and there may be a wrinkle.
No matter how you define the XML mappings, JPA expects persistable fields to
either be real fields (var) on the instance or getter/setter pairs; using an
object for field a la Record still isn't either of these. I have a busy few
weeks ahead but I'm going to do some reading in the meantime and see if we
can come up with something transparent but easy to use.
Derek
On Mon, Dec 15, 2008 at 12:39 AM, Daniel Mueller
wrote:
>
> (Reactivating discussion. I guess it's been discussed more on the
> committer list, but here you have my 2 cents anyway)
>
> For the sake of the Record-JPA discussion, people will fall into two
> categories when they are using lift:
> * The first group of people have an existing, working, tested JPA/OR
> based data access library written in Java and are looking to integrate
> that with a webapp written in lift. They will usually be coming from
> an enterprise background, and will have some constraints on what they
> can develop from scratch ("no - we will not rewrite all the db access
> code to support the new web framework").
> * The second group doesn't have an existing data access library in
> Java and would like to write all their new stuff with lift in Scala.
> But maybe they have mapping/usage requirements that precludes using
> mapper because it's too simple, or they just know their way around one
> of the other JPA enabled OR libs and want to bank on that knowledge
> (without writing the entire layer in Java).
> * The third group also doesn't have an existing data access library,
> but for some reasons, they want their OR model not only be accessible
> from lift, but actually also from Java code. This means that they not
> only have to be able use JPA, but that the Scala code they write has
> to be _JPA compatible_ (Java usable JPA entities etc.).
>
> For the first group, some sort of delegation strategy from the Record
> entity to the JPA entity is necessary (unless you can mixin the record
> stuff on top of an actual JPA entity?). The JPA/OR configuration is
> already in place on the existing lib (annotations/xml). The only thing
> that record is doing is adding another layer on top of it for
> validation, binding to UI, maybe querying. Something like what was
> proposed earlier by Derek should be enough
>
> > class MyEntry extends Record[MyEntry] {
> > var inner : RealEntry = _
> >
> > object name extends StringField(this) with Delegation
> > name.delegate(inner.name, inner.name = _)
> >
> > ...
> > }
>
> Now for the second group, they probably would like to have all the
> power associated with a JPA/OR framework without resolving to writing
> that layer in Java. Mind you that this is quite a different problem
> from what the first group wants to solve.
> * They just want to have Record entities, no separate JPA entity, no
> delegation.
> * They don't want to duplicate configuration from what they already
> specify on Record entities.
> * Have the integration as hassle free as possible, because in their
> eyes, there is no actual delegation.
>
> What the second group needs is a bit trickier, and most of the
> discussion has revolved around how to make it as transparent as
> possible (compiler plugins, byte code weaving, etc.).
>
> Remember that for the second group of people Record is attempting to
> solve the _exact same problem_ as JPA. It's a unifying frontend, that
> abstracts away differences in persistence libraries. And as with JPA,
> Record has the configuration present in code (instead of annotations
> it just uses actual subclasses and parameters, but still).
>
> But there's one thing that has only been mentioned on the off by
> David.
>
> > I believe there are ways to use Record's deep knowledge of class layouts
> to
> > generate data structures and/or XML to send to JPA to "do the right
> thing."
>
> The key point here is XML. While those annotations are a nice feature
> for the programmer to get rid of the XML configuration from pre EJB
> 3.0, it's less than sexy for attaching a unified API (record) to an
> implementation library (jpa, which incidentially is another unified
> API for the actual OR libs :/ ). But that's a feature for the
> developer who doesn't want to specify the configuration in an XML. But
> the XML configuration capability is still there. Generating XML from
> Record entities (maybe even in memory) to boot the JPA/OR lib should
> be pretty easy and doesn't require more opaque techniques (compiler
> plugin, byte code weaving). And it can be overridden easily as well
> even to integrate things that are not supported in Record.
> I'm not well versed enough in JPA to make statements about whether the
> XML configuration is feature complete compared to the annotations, and
> how flexible the mapping can be (directly from the Record object
> fields to the columns). I would assume that the mapping is not
> flexible enough to work with the objects fields from Record,
[Lift] Re: JPA and Record
(Reactivating discussion. I guess it's been discussed more on the
committer list, but here you have my 2 cents anyway)
For the sake of the Record-JPA discussion, people will fall into two
categories when they are using lift:
* The first group of people have an existing, working, tested JPA/OR
based data access library written in Java and are looking to integrate
that with a webapp written in lift. They will usually be coming from
an enterprise background, and will have some constraints on what they
can develop from scratch ("no - we will not rewrite all the db access
code to support the new web framework").
* The second group doesn't have an existing data access library in
Java and would like to write all their new stuff with lift in Scala.
But maybe they have mapping/usage requirements that precludes using
mapper because it's too simple, or they just know their way around one
of the other JPA enabled OR libs and want to bank on that knowledge
(without writing the entire layer in Java).
* The third group also doesn't have an existing data access library,
but for some reasons, they want their OR model not only be accessible
from lift, but actually also from Java code. This means that they not
only have to be able use JPA, but that the Scala code they write has
to be _JPA compatible_ (Java usable JPA entities etc.).
For the first group, some sort of delegation strategy from the Record
entity to the JPA entity is necessary (unless you can mixin the record
stuff on top of an actual JPA entity?). The JPA/OR configuration is
already in place on the existing lib (annotations/xml). The only thing
that record is doing is adding another layer on top of it for
validation, binding to UI, maybe querying. Something like what was
proposed earlier by Derek should be enough
> class MyEntry extends Record[MyEntry] {
> var inner : RealEntry = _
>
> object name extends StringField(this) with Delegation
> name.delegate(inner.name, inner.name = _)
>
> ...
> }
Now for the second group, they probably would like to have all the
power associated with a JPA/OR framework without resolving to writing
that layer in Java. Mind you that this is quite a different problem
from what the first group wants to solve.
* They just want to have Record entities, no separate JPA entity, no
delegation.
* They don't want to duplicate configuration from what they already
specify on Record entities.
* Have the integration as hassle free as possible, because in their
eyes, there is no actual delegation.
What the second group needs is a bit trickier, and most of the
discussion has revolved around how to make it as transparent as
possible (compiler plugins, byte code weaving, etc.).
Remember that for the second group of people Record is attempting to
solve the _exact same problem_ as JPA. It's a unifying frontend, that
abstracts away differences in persistence libraries. And as with JPA,
Record has the configuration present in code (instead of annotations
it just uses actual subclasses and parameters, but still).
But there's one thing that has only been mentioned on the off by
David.
> I believe there are ways to use Record's deep knowledge of class layouts to
> generate data structures and/or XML to send to JPA to "do the right thing."
The key point here is XML. While those annotations are a nice feature
for the programmer to get rid of the XML configuration from pre EJB
3.0, it's less than sexy for attaching a unified API (record) to an
implementation library (jpa, which incidentially is another unified
API for the actual OR libs :/ ). But that's a feature for the
developer who doesn't want to specify the configuration in an XML. But
the XML configuration capability is still there. Generating XML from
Record entities (maybe even in memory) to boot the JPA/OR lib should
be pretty easy and doesn't require more opaque techniques (compiler
plugin, byte code weaving). And it can be overridden easily as well
even to integrate things that are not supported in Record.
I'm not well versed enough in JPA to make statements about whether the
XML configuration is feature complete compared to the annotations, and
how flexible the mapping can be (directly from the Record object
fields to the columns). I would assume that the mapping is not
flexible enough to work with the objects fields from Record, but maybe
we can start discussing strategies to solve that (using vars,
generating bytecode, using untyped maps as entities, generating OR lib
specific XML - And yes I know that with a couple of those you loose
some features provided by JPA).
For the third group of people, those that want to use reuse their
objects as Java compatible JPA entities: Do we really need that right
now? Are there enough real use cases to warrant the effort? Mind that
you can always write a Java compatible access layer for your entities
in Scala. In that layer you refrain from using stuff that Java doesn't
like and then just use that connector from your java code. IMO lift
sho
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
I'm not at my computer right now, but can't you either use github to show you the diff? or just do a diff using your local git repo? Cheers, Tim Sent from my iPhone On 15 Dec 2008, at 08:08, Marius wrote: > > Sorry Dan ... There were too many changes in LiftRules. You should be > able to determine real quick what changed in LiftRules since the > variables naming is more or less the same. > > If you can not fix your code can you please copy-paste it here ? ... > in this way I may be able to help. > > Br's, > Marius > > On Dec 15, 1:55 am, Dano wrote: >> Marius, >> >> Is there someway you can communicate what the 'from' and 'to' changes >> are so that I can have a chance at being able to fix my now broken >> code? >> >> Dan >> >> On Dec 13, 12:31 pm, Marius wrote: >> >>> All, >> >>> I committed a bunch of changes inLiftRules. In a previous thread >>> Jorge suggested the abstraction ofLiftRulesvariables. Lists of >>> functions are now abstracted by RulesSeq trait, which contains >>> prepend >>> and append functions. Note that if you're calling prepend/append >>> functions after boot they will throw an exception. If there are >>> compelling reasons not to do this please let us know. This is just a >>> mechanism to enforce the use of these functions on startup. >> >>> Br's, >>> Marius > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
On Sun, Dec 14, 2008 at 10:46 PM, Marius wrote:
>
> So LiftConfig would take the role of LiftRules from API perspective
> meaning that LiftRules could be completely hidden from Lift users but
> available internally to Lift only ?
Since LiftRules would then only expose immutable data, I'd see no problem
exposing it if there is value in exposing it.
But keeping it private is a very viable strategy.
>
>
> Still from maintainability perspective initializing LifRules with a
> LiftConfig may imply lots of assignments (unless LiftRules will
> reference a LiftConfig in which case LiftRules code needs to change to
> use LiftConfig) or when we'd want to expose some new stuff we'd have
> to add it in two different places LiftConfig toexpose it to users and
> LiftRules so that Lift code to use that.
Yes, there'd be quite a few assignments, but with a nifty unit test you
could secure that everything is used properly.
Cheers,
Viktor
>
>
> Otherwise not a bad idea ...
>
> Br's,
> Marius
>
> On Dec 14, 5:21 pm, "Viktor Klang" wrote:
> > On Sun, Dec 14, 2008 at 4:01 PM, David Pollak <
> feeder.of.the.be...@gmail.com
> >
> >
> >
> > > wrote:
> >
> > > On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang >wrote:
> >
> > >> David,
> >
> > >> sounds reasonable.
> >
> > >> So being able to call prepend/append after boot() makes no sense.
> >
> > >> In the light of htis, it shouldn't be possible to call the
> prepend/append
> > >> outside of boot.
> > >> I suggest my approach described previously. (Injecting an
> initialization
> > >> context into boot and use that to configure LiftRules, then we don't
> expose
> > >> the mutativity in LiftRules.
> > >> Result: No runtime exceptions, no confusion on when to configure the
> > >> webapp etc.
> >
> > > I have no idea what this means or how to translate it into code. Can
> you
> > > give me an example of code that "injects an initialization context into
> > > boot"?
> >
> > class Boot
> > {
> >def boot(val lc: LiftConfig) =
> >{
> > add all configuration to LiftConfig
> >}
> >
> > }
> >
> > and then in the code that lookups, creates and calls Boot.boot (haven't
> got
> > access to the repository on this machine)
> >
> > just add/modify the code in the bootstrap loader:
> >
> > {
> > val boot = ...//Lookup and create Boot instance
> > val lc = LiftConfig() //(1)
> > boot.boot(lc) //(2)
> > LiftRules.init(lc) //(3)
> >
> > }
> >
> > (1) : Must create LiftConfig (this object is the placeholder of the
> > configuration=
> > (2) : Pass it into the boot-call
> > (3) : Initialize LiftRules with the configuration prepared by the
> boot-call
> >
> > result:
> >
> > No need to expose mutability in LiftRules (since we discovered that
> changing
> > stuff while the webserver was up and running had few applications at
> best)
> >
> > More clear now?
> >
> > Remeber that this is only a friendly suggestion to an issue brought up by
> > someone else in this thread.
> > If such suggestions are superflous, please just tell me so and I'll keep
> my
> > trap shut.
> >
> > Cheers,
> > Viktor
> >
> >
> >
> >
> >
> > >> Input?
> >
> > >> Cheers,
> > >> Viktor
> >
> > >> On Sun, Dec 14, 2008 at 3:41 PM, David Pollak <
> > >> feeder.of.the.be...@gmail.com> wrote:
> >
> > >>> Folks,
> >
> > >>> I have not had a single instance of wanting to change global
> application
> > >>> behavior at runtime. I cannot think of use case for such a feature.
> >
> > >>> On the other hand, the idea that your program behavior is stable from
> the
> > >>> first HTTP request on makes a lot of sense to me. It means tests
> work
> > >>> because the tests don't have to worry about the behavior of the
> program
> > >>> changing. The same n steps will lead to the same result.
> >
> > >>> If anyone can come up with a use case for globally changing program
> > >>> behavior during program execution, I'm all ears, but barring that,
> once the
> > >>> boot phase is over, the stuff in LiftRules should be frozen.
> >
> > >>> Thanks,
> >
> > >>> David
> >
> > >>> On Sun, Dec 14, 2008 at 3:54 AM, Marius
> wrote:
> >
> > On Dec 14, 12:53 pm, "Viktor Klang" wrote:
> > > On Sun, Dec 14, 2008 at 11:42 AM, Marius >
> > wrote:
> >
> > > > On Dec 14, 12:10 pm, "Viktor Klang"
> wrote:
> > > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius <
> marius.dan...@gmail.com>
> > wrote:
> >
> > > > > > On Dec 14, 3:02 am, "Jorge Ortiz"
> > wrote:
> > > > > > > Not to beat a dead horse, but... what's the rationale,
> again,
> > for
> > > > > > throwing
> > > > > > > an exception after boot? Is there a real danger to some or
> all
> > > > RulesSeqs
> > > > > > > being mutable after boot? If some, then those rules should
> > > > selectively be
> > > > > > > protected. Even if they're all dangerous, there are better
> > (i.e.,
> > > > type
> > > > > > safe)
> > > > > > > ways of protecting RulesSeqs from mutation than just
> thr
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano wrote: > Marius, > > Is there someway you can communicate what the 'from' and 'to' changes > are so that I can have a chance at being able to fix my now broken > code? > > Dan > > On Dec 13, 12:31 pm, Marius wrote: > > > All, > > > I committed a bunch of changes inLiftRules. In a previous thread > > Jorge suggested the abstraction ofLiftRulesvariables. Lists of > > functions are now abstracted by RulesSeq trait, which contains prepend > > and append functions. Note that if you're calling prepend/append > > functions after boot they will throw an exception. If there are > > compelling reasons not to do this please let us know. This is just a > > mechanism to enforce the use of these functions on startup. > > > Br's, > > Marius --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
