[Lift] JS compression with the Alchim maven plugin?
Hello all, has anyone managed to use the Alchim/YUI JS compressor (referenced in the basic lift archetype) in a project? When I create a blank Lift project and add any kind of JS file in the src/main/webapp (or similar) folder, the compilation (or rather, resource compression goal) fails with the following stack trace: http://pastebin.com/m8de90c4 I have not been able to find any specific LOC in my JS files that could cause this exception, and haven't been able to debug the plugin since I lack the source code (the repository is broken). Has anyone had the same problems, or could someone point me to a project where the plugin works? I would really like to get this working. Thanks, dflemstr --~--~-~--~~~---~--~~ 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: Anyone working on the flot widget?
> Make sure you're trying to plot the same data with the same plot options.
Well, that's an easy one, since the bug appears in all graphs with
legends, everywhere.
> I'm basically in the same boat and will probably clone the
> lift-widgets module on github and work from there (I'm not a Lift
> committer). I hope Francois will then commit the changes to Lift at
> some point :-) I think we should coordinate the effort to avoid
> wasting resources. Let me know what you think
>
> /Jeppe
The beauty of GitHub is that you can just fork the repository, and
send a fork merge request when you're done. No one who has commit
access needs to review your code, but instead simply accept your
request. I think that that's what I'll do.
Oh, and I have the solution to the problem (and it's something really,
really stupid):
The default Bluetype CSS theme, in the screen.css file, has a "width:
100%;" attribute in a raw "table" selector. This is what causes the
problem.
If I only had had FireBug earlier...
To fix the bug, we need to create a stylesheet for Flot that resets
some options. If someone with repository access will pull my fork
afterwards, I'll make one (and clean up a little of the Flot code
while I'm at it). Otherwise, I would be happy if someone simply would
fix this issue; it just requires adding this to a CSS file of choice
(where the-graph-id is inserted dynamically):
#the-graph-id .legend table {
width: auto !important;
}
Still, the bug remains with the legend issues; it's not possible to
have an external legend for some reason.
--~--~-~--~~~---~--~~
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: Anyone working on the flot widget?
Follow-up on my other reply: When using the latest Flot 0.5 version, the exact same bug appears when using it with the widgets.flot module. I am absolutely certain that I am loading the correct Flot JS files (I haven't shadowed the old resource path, but instead forked the whole Flot widget library and changed all of the paths in it). This bug appears in Firefox (which is very serious) as well as in other browsers based on WebKit/ Gecko/KHTML. As can be seen here: http://bit.ly/13EEnw , the bug isn't present in the vanilla Flot library. I am at a loss to find the bug causing all this. The whole Flot widget seems to be very messy (it consists of 30% commented-away code, for instance) and I would be happy to help improve it once and for all, since I'm in need of the Flot library for a project. On Jun 27, 9:50 am, Jeppe Nejsum Madsen wrote: > dflemstr writes: > > Hello everyone involved, > > I am having a very annoying problem with the Flot widget: The > > automatically generated legend's auto-sizing feature is broken (it > > grows horizontally to the max allowed space while still adhering to > > the margin values specified, and it's not possible to create an > > external, custom legend) as demonstrated by this screenshot: > >http://bit.ly/uKE9o > > > This bug is present in 1.1-M1 as well as 1.1-SNAPSHOT, isn't caused by > > me (since it is present int he demo app) and seems to originate from > > something on the client-side (obviously). > > > Does anyone have a solution to this problem, or if not, can I make a > > fork of the widgets module, try to fix the problem, and commit it > > back? This little inconvenience removes much of the visual quality of > > plots, so a solution to it would be very much appreciated. > > I haven't looked in detail but: Is this a problem with the widget or the > Flot library? As far as I know, the widget is just a thin wrapper on top > of the Flot JS library. If it's a problem with the JS, you should > probably try to fix this upstream:http://code.google.com/p/flot/ > > /Jeppe --~--~-~--~~~---~--~~ 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: Anyone working on the flot widget?
If this indeed is an upstream bug (I'll have to try to re-implement the "Flot" object with an alternate resource file to check; annoying that such things are hardcoded), then the only solution to it would be to update the flot widget to a newer version anyways, so some work needs to be done on the widget module whichever way you choose. It appears, however, that you don't have the same problem? Is this the case? Oh, and by the way, is scala-tools.org down? Maven complains about it. /dflemstr On Jun 27, 9:50 am, Jeppe Nejsum Madsen wrote: > dflemstr writes: > > Hello everyone involved, > > I am having a very annoying problem with the Flot widget: The > > automatically generated legend's auto-sizing feature is broken (it > > grows horizontally to the max allowed space while still adhering to > > the margin values specified, and it's not possible to create an > > external, custom legend) as demonstrated by this screenshot: > >http://bit.ly/uKE9o > > > This bug is present in 1.1-M1 as well as 1.1-SNAPSHOT, isn't caused by > > me (since it is present int he demo app) and seems to originate from > > something on the client-side (obviously). > > > Does anyone have a solution to this problem, or if not, can I make a > > fork of the widgets module, try to fix the problem, and commit it > > back? This little inconvenience removes much of the visual quality of > > plots, so a solution to it would be very much appreciated. > > I haven't looked in detail but: Is this a problem with the widget or the > Flot library? As far as I know, the widget is just a thin wrapper on top > of the Flot JS library. If it's a problem with the JS, you should > probably try to fix this upstream:http://code.google.com/p/flot/ > > /Jeppe --~--~-~--~~~---~--~~ 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: Anyone working on the flot widget?
Hello everyone involved, I am having a very annoying problem with the Flot widget: The automatically generated legend's auto-sizing feature is broken (it grows horizontally to the max allowed space while still adhering to the margin values specified, and it's not possible to create an external, custom legend) as demonstrated by this screenshot: http://bit.ly/uKE9o This bug is present in 1.1-M1 as well as 1.1-SNAPSHOT, isn't caused by me (since it is present int he demo app) and seems to originate from something on the client-side (obviously). Does anyone have a solution to this problem, or if not, can I make a fork of the widgets module, try to fix the problem, and commit it back? This little inconvenience removes much of the visual quality of plots, so a solution to it would be very much appreciated. /dflemstr On Jun 25, 2:13 pm, Jeppe Nejsum Madsen wrote: > On 25 Jun 2009, Francois Bertrand wrote: > > > Hi Jeppe > > > Great to see you are interested in the flot widget. > > > My current to-do list for the flot widget, is: > > > - create more Lift JsExp and JsCmd to modify a already displayed flot > > graph. They should be used in AJAX and Comet applications > > > - update to a more recent version of the javascrrit widget > > I need this as well, especially since there are some patches that > provides pie charts > > > > > - create the test demo app, > > > - make the creation of FlotOptions, FlotLinesOptions, etc, less > > verbose. I hope that Scala 2.8 Named and Default Arguments will help. > > Yeah, this would be nice :-) We probably need some working code within > the next few weeks so probably can't wait for 2.8 though. > > > - create a high level mechanism to display Lift's Record > > > I appreciate any help. > > What's the best way to coordinate this? Just fork the code on github or? > > /Jeppe --~--~-~--~~~---~--~~ 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: Making MetaMegaProtoUser "templateable"
(Note: I submitted a response to this Google group a while ago, but it
hasn't appeared yet, ~4 hours later, so I'm reposting)
Hello again, and thanks for the solution; it's not obvious at all and
could be very difficult to find a sustainable solution for.
One thing that springs to mind is that you could change the params of
"bind" from (String, NodeSeq) to (String, => NodeSeq) (and BindParam
too of course); then the values will be lazy inside of the bind
implementation and the user won't notice any difference. This breaks
binary compatibility, though, so you might be able to find something
better.
Anyways, thanks for the solution to my little problem!
(PS: you could put "_: NodeSeq" instead of "ignore: NodeSeq" above;
the Scala compiler might be able to optimize the code better then)
On Jun 20, 1:13 am, David Pollak
wrote:
> Okay... this was the hardest problem I've dealt with in a while.
> Lift processed form elements in the order that they are created. Usually,
> the order that they are created is the order they appear in bind.
>
> However, that is not the case here because the binding to "field" is a
> function that is evaluated when each field element is encountered, but the
> submit button is bound when it's encountered in the bind() method... so the
> submit button gets bound before the form elements and because of that the
> functions for the form elements never get run because the submit does a
> redirect which internally to Lift throws an exception. The Dog was in fact
> getting saved to the RDBMS, but with its original values.
>
> The short answer on how to fix the problem is to change:
> def innerEdit = bind("dog", xhtml,
> "field" -> ((x: NodeSeq) => localForm(x, dogToEdit)),
> "submit" -> SHtml.submit("Edit", testEdit _))
>
> to:
>
> def innerEdit = bind("dog", xhtml,
> "field" -> ((x: NodeSeq) => localForm(x, dogToEdit)),
> "submit" -> ((ignore: NodeSeq) => SHtml.submit("Edit", testEdit _)))
>
> The submit button will be evaluated lazily and last. This will fix the
> problem.
>
> Now... I have to figure out what to do in the broader case because the lazy
> vs. strict evaluation will cause this subtle thing to happen again and again
> and it's amazingly non-trivial to figure it out.
>
> Thanks,
>
> David
>
> 2009/6/19 dflemstr
>
>
>
> > Hello again,
> > thank you so much for your time. My fork is located here:
> > git://github.com/dflemstr/lift_1_1_sample.git
>
> > The code is very straightforward and I removed all unnecessary
> > constructs (such as the User.scala file) so it should be really clear
> > what the problem is now.
>
> > On Jun 19, 7:06 pm, David Pollak
> > wrote:
> > > 2009/6/19 dflemstr
>
> > > > Well, OK, I'm sorry everyone, I should have been more clear:
> > > > The goal that I have is to make a snippet that creates a templated
> > > > edit form for me. However, this is not the >issue< which I want to
> > > > discuss. The issue is that when I try to make this snippet (and this
> > > > could have been any snippet, since the principles are the same), I am
> > > > unable to, because somewhere the instance of the Mapper for which I
> > > > want to create the snippet (in this case it's a MetaMegaProtoUser)
> > > > gets lost, and thus no changes are preserved.
>
> > > I am very confused. I don't understand what "gets lost" means?
>
> > > > The reason why I
> > > > mentioned the templating in the first place is because I basically use
> > > > exactly the same code as in the default MetaMegaProtoUser.edit method,
> > > > just adding some bind calls and an extra parameter: the template
> > > > NodeSeq, and suddenly the code breaks.
>
> > > A compiler error? An exception? What kind of break do you mean?
>
> > > > As mentioned before, any
> > > > changes I make in the client aren't saved. I have no good way of
> > > > checking whether the changes even are contained within the POST(→it's
> > > > the localForm's fault) or if the User instance gets lost earlier
> > > > (→it's some closure that fails somewhere), but the testEdit function
> > > > gets called for sure, but with the wrong user instance.
>
> > > I think the best thing to do with discuss in code. I've created a simple
> > > project athttp://github.com/dpp/lift_1_1_sample/tree/master
>
> > > Plea
[Lift] Re: Making MetaMegaProtoUser "templateable"
Hello again and thank you for this solution!
This is indeed a strange problem and it's difficult to find a good
sustainable solution... One such that I think would be appropriate,
however, would be to make bind take (String, => NodeSeq) instead of
(String, NodeSeq) - the BindParam class would have to be changed too
of course - and then just to evaluate the value on demand. This
wouldn't break any code AFAIK, and would be the most manageable
solution. However, you will probably come up with something more
suitable; my solution isn't binary compatible, which might be an
issue, for example.
Anyways, thanks for the solution to my problem!
/dflemstr
On Jun 20, 1:13 am, David Pollak
wrote:
> Okay... this was the hardest problem I've dealt with in a while.
> Lift processed form elements in the order that they are created. Usually,
> the order that they are created is the order they appear in bind.
>
> However, that is not the case here because the binding to "field" is a
> function that is evaluated when each field element is encountered, but the
> submit button is bound when it's encountered in the bind() method... so the
> submit button gets bound before the form elements and because of that the
> functions for the form elements never get run because the submit does a
> redirect which internally to Lift throws an exception. The Dog was in fact
> getting saved to the RDBMS, but with its original values.
>
> The short answer on how to fix the problem is to change:
> def innerEdit = bind("dog", xhtml,
> "field" -> ((x: NodeSeq) => localForm(x, dogToEdit)),
> "submit" -> SHtml.submit("Edit", testEdit _))
>
> to:
>
> def innerEdit = bind("dog", xhtml,
> "field" -> ((x: NodeSeq) => localForm(x, dogToEdit)),
> "submit" -> ((ignore: NodeSeq) => SHtml.submit("Edit", testEdit _)))
>
> The submit button will be evaluated lazily and last. This will fix the
> problem.
>
> Now... I have to figure out what to do in the broader case because the lazy
> vs. strict evaluation will cause this subtle thing to happen again and again
> and it's amazingly non-trivial to figure it out.
>
> Thanks,
>
> David
>
> 2009/6/19 dflemstr
>
>
>
> > Hello again,
> > thank you so much for your time. My fork is located here:
> > git://github.com/dflemstr/lift_1_1_sample.git
>
> > The code is very straightforward and I removed all unnecessary
> > constructs (such as the User.scala file) so it should be really clear
> > what the problem is now.
>
> > On Jun 19, 7:06 pm, David Pollak
> > wrote:
> > > 2009/6/19 dflemstr
>
> > > > Well, OK, I'm sorry everyone, I should have been more clear:
> > > > The goal that I have is to make a snippet that creates a templated
> > > > edit form for me. However, this is not the >issue< which I want to
> > > > discuss. The issue is that when I try to make this snippet (and this
> > > > could have been any snippet, since the principles are the same), I am
> > > > unable to, because somewhere the instance of the Mapper for which I
> > > > want to create the snippet (in this case it's a MetaMegaProtoUser)
> > > > gets lost, and thus no changes are preserved.
>
> > > I am very confused. I don't understand what "gets lost" means?
>
> > > > The reason why I
> > > > mentioned the templating in the first place is because I basically use
> > > > exactly the same code as in the default MetaMegaProtoUser.edit method,
> > > > just adding some bind calls and an extra parameter: the template
> > > > NodeSeq, and suddenly the code breaks.
>
> > > A compiler error? An exception? What kind of break do you mean?
>
> > > > As mentioned before, any
> > > > changes I make in the client aren't saved. I have no good way of
> > > > checking whether the changes even are contained within the POST(→it's
> > > > the localForm's fault) or if the User instance gets lost earlier
> > > > (→it's some closure that fails somewhere), but the testEdit function
> > > > gets called for sure, but with the wrong user instance.
>
> > > I think the best thing to do with discuss in code. I've created a simple
> > > project athttp://github.com/dpp/lift_1_1_sample/tree/master
>
> > > Please fork the repository and enhance the code to edit the Dog object...
> > > your code doesn't have to compile or run, but if I can see where you're
> >
[Lift] Re: Making MetaMegaProtoUser "templateable"
Hello again, thank you so much for your time. My fork is located here: git://github.com/dflemstr/lift_1_1_sample.git The code is very straightforward and I removed all unnecessary constructs (such as the User.scala file) so it should be really clear what the problem is now. On Jun 19, 7:06 pm, David Pollak wrote: > 2009/6/19 dflemstr > > > > > Well, OK, I'm sorry everyone, I should have been more clear: > > The goal that I have is to make a snippet that creates a templated > > edit form for me. However, this is not the >issue< which I want to > > discuss. The issue is that when I try to make this snippet (and this > > could have been any snippet, since the principles are the same), I am > > unable to, because somewhere the instance of the Mapper for which I > > want to create the snippet (in this case it's a MetaMegaProtoUser) > > gets lost, and thus no changes are preserved. > > I am very confused. I don't understand what "gets lost" means? > > > The reason why I > > mentioned the templating in the first place is because I basically use > > exactly the same code as in the default MetaMegaProtoUser.edit method, > > just adding some bind calls and an extra parameter: the template > > NodeSeq, and suddenly the code breaks. > > A compiler error? An exception? What kind of break do you mean? > > > As mentioned before, any > > changes I make in the client aren't saved. I have no good way of > > checking whether the changes even are contained within the POST(→it's > > the localForm's fault) or if the User instance gets lost earlier > > (→it's some closure that fails somewhere), but the testEdit function > > gets called for sure, but with the wrong user instance. > > I think the best thing to do with discuss in code. I've created a simple > project athttp://github.com/dpp/lift_1_1_sample/tree/master > > Please fork the repository and enhance the code to edit the Dog object... > your code doesn't have to compile or run, but if I can see where you're > having problems, I can work to resolve them and to help you get over this > hump. Point out where you're running into problems and I'll fix up the code > to work the way you want it to. > > Thanks, > > David > > > > > Hopefully I've made my problem more clear. > > > On Jun 19, 6:19 pm, David Pollak > > wrote: > > > On Fri, Jun 19, 2009 at 3:25 AM, dflemstr > > wrote: > > > > > Well, that probably is good advice, but doesn't really relate to the > > > > matter at hand if I understand you correctly. > > > > As you may notice, the code is a modified version of the embedded > > > > code, but it's completely independent from it (it doesn't override > > > > anything). It could have been code that had been written completely by > > > > me. > > > > > And anyways, my goal is to make a snippet out of the edit form, and > > > > not to just be able to load a template from a file (I need to put the > > > > whole edit form in multiple, obscure places) so your solution, I must > > > > say, isn't any help to me. Maybe my original message title was > > > > misleading. > > > > I am totally confused as to what your goal is? Is it to put the form > > into a > > > template file (a .html) file? Is it to control the rendering of the form > > > elements? Is it something else? > > > > In terms of ProtoUser, that class is meant as a quick bootstrap to > > getting > > > your project going. It lends itself nicely to adding fields. Any > > styling > > > needs to be done via CSS. If you need something more complex (like ESME > > > does), you can pull the code into your User class and then work to > > achieve > > > the particular goal. If we can cycle a bit on what your particular goal > > is, > > > I'm sure we can get you there. > > > > > The issue is that the theUser object isn't preserved between requests. > > > > Apart from that, the snippet could've been any other snippet (because > > > > it's just being used as a generic mapper; I could've created this form > > > > for any structure). > > > > > Thank you for your effort, anyhow! > > > > > On Jun 19, 6:21 am, David Pollak > > > > wrote: > > > > > I'd suggest copying/pasting the code from ProtoUser and MegaProtoUser > > and > > > > > munging the code so that you don't have to work around th
[Lift] Re: Making MetaMegaProtoUser "templateable"
Well, OK, I'm sorry everyone, I should have been more clear:
The goal that I have is to make a snippet that creates a templated
edit form for me. However, this is not the >issue< which I want to
discuss. The issue is that when I try to make this snippet (and this
could have been any snippet, since the principles are the same), I am
unable to, because somewhere the instance of the Mapper for which I
want to create the snippet (in this case it's a MetaMegaProtoUser)
gets lost, and thus no changes are preserved. The reason why I
mentioned the templating in the first place is because I basically use
exactly the same code as in the default MetaMegaProtoUser.edit method,
just adding some bind calls and an extra parameter: the template
NodeSeq, and suddenly the code breaks. As mentioned before, any
changes I make in the client aren't saved. I have no good way of
checking whether the changes even are contained within the POST(→it's
the localForm's fault) or if the User instance gets lost earlier
(→it's some closure that fails somewhere), but the testEdit function
gets called for sure, but with the wrong user instance.
Hopefully I've made my problem more clear.
On Jun 19, 6:19 pm, David Pollak
wrote:
> On Fri, Jun 19, 2009 at 3:25 AM, dflemstr wrote:
>
> > Well, that probably is good advice, but doesn't really relate to the
> > matter at hand if I understand you correctly.
> > As you may notice, the code is a modified version of the embedded
> > code, but it's completely independent from it (it doesn't override
> > anything). It could have been code that had been written completely by
> > me.
>
> > And anyways, my goal is to make a snippet out of the edit form, and
> > not to just be able to load a template from a file (I need to put the
> > whole edit form in multiple, obscure places) so your solution, I must
> > say, isn't any help to me. Maybe my original message title was
> > misleading.
>
> I am totally confused as to what your goal is? Is it to put the form into a
> template file (a .html) file? Is it to control the rendering of the form
> elements? Is it something else?
>
> In terms of ProtoUser, that class is meant as a quick bootstrap to getting
> your project going. It lends itself nicely to adding fields. Any styling
> needs to be done via CSS. If you need something more complex (like ESME
> does), you can pull the code into your User class and then work to achieve
> the particular goal. If we can cycle a bit on what your particular goal is,
> I'm sure we can get you there.
>
>
>
>
>
> > The issue is that the theUser object isn't preserved between requests.
> > Apart from that, the snippet could've been any other snippet (because
> > it's just being used as a generic mapper; I could've created this form
> > for any structure).
>
> > Thank you for your effort, anyhow!
>
> > On Jun 19, 6:21 am, David Pollak
> > wrote:
> > > I'd suggest copying/pasting the code from ProtoUser and MegaProtoUser and
> > > munging the code so that you don't have to work around the embedded
> > > MegaProtoUser code. Seehttp://
> > svn.apache.org/viewvc/incubator/esme/trunk/server/src/main/sca...
> > > I recently made this change to the
>
> > > On Thu, Jun 18, 2009 at 1:51 PM, dflemstr
> > wrote:
>
> > > > Hello everyone,
> > > > I'm having some problems with making the MetaMegaProtoUser "edit"
> > > > method templateable (because I believe in the concept of separating
> > > > content and design) and am succeeding quite well, except for with one
> > > > little detail: I can't make my changes in the edit form persistent; it
> > > > seems that the "User" instance gets lost somewhere in the process and
> > > > that all the client-side changes therefore also get lost.
>
> > > > The code is at the end of the message. The edit method is called with
> > > > a template which also is at the very end of the message.
>
> > > > I would really appreciate if anyone with more Lift experience than me
> > > > could spot the mistake, because I simply cannot find it.
>
> > -
> > > > The "snippet" (inside a subclass of MetaMegaProtoUser):
>
> > > > /** Create an edit form with the specified template */
> > > > def edit(xhtml: NodeSeq) = {
> > > >val theUser: User = currentUser.open_! // we know we're logged in
>
> > > >def te
[Lift] Re: Making MetaMegaProtoUser "templateable"
Well, that probably is good advice, but doesn't really relate to the
matter at hand if I understand you correctly.
As you may notice, the code is a modified version of the embedded
code, but it's completely independent from it (it doesn't override
anything). It could have been code that had been written completely by
me.
And anyways, my goal is to make a snippet out of the edit form, and
not to just be able to load a template from a file (I need to put the
whole edit form in multiple, obscure places) so your solution, I must
say, isn't any help to me. Maybe my original message title was
misleading.
The issue is that the theUser object isn't preserved between requests.
Apart from that, the snippet could've been any other snippet (because
it's just being used as a generic mapper; I could've created this form
for any structure).
Thank you for your effort, anyhow!
On Jun 19, 6:21 am, David Pollak
wrote:
> I'd suggest copying/pasting the code from ProtoUser and MegaProtoUser and
> munging the code so that you don't have to work around the embedded
> MegaProtoUser code.
> Seehttp://svn.apache.org/viewvc/incubator/esme/trunk/server/src/main/sca...
> I recently made this change to the
>
>
>
> On Thu, Jun 18, 2009 at 1:51 PM, dflemstr wrote:
>
> > Hello everyone,
> > I'm having some problems with making the MetaMegaProtoUser "edit"
> > method templateable (because I believe in the concept of separating
> > content and design) and am succeeding quite well, except for with one
> > little detail: I can't make my changes in the edit form persistent; it
> > seems that the "User" instance gets lost somewhere in the process and
> > that all the client-side changes therefore also get lost.
>
> > The code is at the end of the message. The edit method is called with
> > a template which also is at the very end of the message.
>
> > I would really appreciate if anyone with more Lift experience than me
> > could spot the mistake, because I simply cannot find it.
>
> > -
> > The "snippet" (inside a subclass of MetaMegaProtoUser):
>
> > /** Create an edit form with the specified template */
> > def edit(xhtml: NodeSeq) = {
> >val theUser: User = currentUser.open_! // we know we're logged in
>
> >def testEdit() {
> > theUser.validate match {
> >case Nil =>
> > theUser.save
> > S.notice("Profile updated") //The Lift Core has a spelling
> > mistake in its translation, so I don't use S.??
> > S.redirectTo(homePage)
>
> >case xs =>
> > S.error(xs)
> > S.mapSnippet(S.currentSnippet.open_!, innerEdit)
> > }
> >}
>
> >def innerEdit(t: NodeSeq) = bind("user", t,
> >"field" -> ((h: NodeSeq) => localForm
> > (h, theUser, true)),
> >"submit" -> SHtml.submit(S.??("edit"),
> > testEdit _))
> >innerEdit(xhtml)
> > }
>
> > /** Make a form with all the editable fields of an user, from a
> > template */
> > protected def localForm(xhtml: NodeSeq, user: User, ignorePassword:
> > Boolean): NodeSeq = {
> >signupFields
> > .map(fi => getSingleton.getActualBaseField(user, fi)) //get
> > actual fields
> > .filter(f => !ignorePassword || (f match { //remove the password
> > field
> >case f: MappedPassword[_] => false
> >case _ => true
> > }))
> > .flatMap(f =>
> > bind("field", xhtml,
> >"name" -> Text(f.displayName),
> >"form" -> f.toForm)
> >)
> > }
>
> > -
> > The template:
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> 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] Making MetaMegaProtoUser "templateable"
Hello everyone,
I'm having some problems with making the MetaMegaProtoUser "edit"
method templateable (because I believe in the concept of separating
content and design) and am succeeding quite well, except for with one
little detail: I can't make my changes in the edit form persistent; it
seems that the "User" instance gets lost somewhere in the process and
that all the client-side changes therefore also get lost.
The code is at the end of the message. The edit method is called with
a template which also is at the very end of the message.
I would really appreciate if anyone with more Lift experience than me
could spot the mistake, because I simply cannot find it.
-
The "snippet" (inside a subclass of MetaMegaProtoUser):
/** Create an edit form with the specified template */
def edit(xhtml: NodeSeq) = {
val theUser: User = currentUser.open_! // we know we're logged in
def testEdit() {
theUser.validate match {
case Nil =>
theUser.save
S.notice("Profile updated") //The Lift Core has a spelling
mistake in its translation, so I don't use S.??
S.redirectTo(homePage)
case xs =>
S.error(xs)
S.mapSnippet(S.currentSnippet.open_!, innerEdit)
}
}
def innerEdit(t: NodeSeq) = bind("user", t,
"field" -> ((h: NodeSeq) => localForm
(h, theUser, true)),
"submit" -> SHtml.submit(S.??("edit"),
testEdit _))
innerEdit(xhtml)
}
/** Make a form with all the editable fields of an user, from a
template */
protected def localForm(xhtml: NodeSeq, user: User, ignorePassword:
Boolean): NodeSeq = {
signupFields
.map(fi => getSingleton.getActualBaseField(user, fi)) //get
actual fields
.filter(f => !ignorePassword || (f match { //remove the password
field
case f: MappedPassword[_] => false
case _ => true
}))
.flatMap(f =>
bind("field", xhtml,
"name" -> Text(f.displayName),
"form" -> f.toForm)
)
}
-
The template:
--~--~-~--~~~---~--~~
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] MappedFields depending on one another
Hello everyone,
I am currently using the Mapper framework to create a very complex
data storage system. In this system, I have the need of changing one
or more MappedFields depending on another MappedField, for example:
trait NonUserEditable
object MyMapper extends LongKeyedMetaMapper[MyMapper] with CRUDify
class MyMapper extends LongKeyedMapper[MyMapper] with IdPK {
def getSingleton = MyMapper
object field1 extends MappedString(this, 64) with LifecycleCallbacks
{
override def beforeValidationOnUpdate {field2(is.capitalize);
super.beforeValidationOnUpdate}
}
object field2 extends MappedString(this, 64) with NonUserEditable
}
I am now looking for the most elegant way to do this; I need
validations on both fields above (which the above code doesn't allow),
and I would like to use CRUDify as much as possible (which might be
overkill but who knows).
So, the goal is to allow for the following process :
1. The user submits a form containing data for field1 through CRUDify
(→ done)
2. The data is stored in field1 by crudDoForm (→ done)
3. field1 is validated, but not field2 (→ How would I do this? Do I
need to rewrite crudDoForm? Because now all fields are validated in
one go, without filtering)
4. Some custom action in field1 is invoked that changes field2 (→ I
can do this with afterValidationOnUpdate if the above point succeeds,
but not otherwise)
5. field2 is changed (→ done, in the custom action)
6. field2 is validated (→ done)
7. Any errors from validations are displayed to the user (→ Can this
be done? Specifically, can I validate field2 in the same cycle as
field1?)
I have hacked CRUDify with a NonUserEditable trait as demonstrated
above (but my hacks are not ;) ) so that CRUDify doesn't include some
fields in its "create" form (dbIncludeInForm_? is BROKEN; the CRUD
"list" doesn't display the hidden field when overriding
dbIncludeInForm_?), so think of the field2 as completely hidden to the
user in the create form. The only problems remaining are the ones
listed above.
Any suggestions on how to solve this would be greatly appreciated.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
