[Lift] Re: Forms validation formatter
Hello, Sorry for the delay in my response, but I only get to play with lift on the weekends, and I wanted to look into your suggestions in more detail. I ported the toForm code from Record to Mapper (and by port, I mean mostly cut'n'paste). While doing so, I noticed 2 things: - Why not provide the same template mechanism used for forms for HTML output? This way I can reuse the same template for both - given that my records have at least dozens, if not even hundreds, of fields, that'd be a great help. - The templates require the use of lift:field and similar tags. I thought I'd be really smart, and created a HTML file A with lift-tags (lift:SomeClass.add.../lift:SomeClass.add) to run my snippet, and used the lift:field tags as children to lift:SomeClass.add. This way, I can create my templates externally, and use the normal lift dispatch-from-view mechanism. And, to save me some more work, the actual form template is in a separate, reusable, HTML file B, to be embedded into A. Embedding, of course, requires eager evaluation. Fine. No. With eager evaluation, lift of course complains that there is no class field, as referenced by lift:field. Now me's wondering whether a separate namespace would be more appropriate? (I did switch to a different namespace, liftf, out of necessity, but I figure that other people might have similar issues) As to the original discussion: I still strongly believe that toForm and to/as(X)Html should not be in Mapper/Record. Different story for JSON/XML/SQL - those seem to me to be rather functionality complete, no problem. But form and html creation seem to be something that most users will want to adapt to their application's needs eventually - state dependent css classes, javascript validation, AJAX form updates... In the examples that I've seen so far, this functionality was dealt with in the snippet. So, either mapper/record eventually become this super- omnipotent-mega-classes that can deal with this functionality to (field.toJavaScriptValidatingAndIncrementallyAjaxUpdatingForm ...), or form/html generation happens in multiple locations, or the user has to override some functions from mapper/record/fields. My beef with this is A) that the respective function calls, given their current signature, require the respective mapper/record-objects to be fully aware of application state for more complex applications; and B) that it is my understanding that overriding internal classes of a framework is a bad thing - I'd rather see a proper application of the Hollywood principle. Just wanted to provide an outsider's feedback. Overall, I think lift's just fantastic. Thank you for listening/reading, Clemens On 19-Mar-09, at 1:08 PM, marius d. wrote: On Mar 18, 11:24 pm, Clemens clemens.oer...@gmail.com wrote: Thank you for your patience, Marius. Well you can use different RecordMeta implementations if you need to different representation of a record without sequential template change. So no state dependency. , b I'm really not trying to be difficultut having multiple RecordMeta instances, for which the HTML output seems to be only one of many functionalities, seems to be shooting with canons at sparrows. Having a toForm functions that takes some template provider as input could be one option. Well this is kinda already in there but it's private :) ... See: private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq so to me makes sense to relax it ... to public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq ... thanks for reminding me about this :) Anyways, I was not even thinking at record level, but rather at field level. See below. Well keeping close view representation and backend abstraction makes a lot of sense as it reduces lots of complexity. Having records/ mappers that know how to represent themselves in different contexts (DB, xhtml) brings a lot of benefits an simplicity. I admit thought that (Btw, by context I meant different HTML display contexts.) I agree that a field should be able to provide hints about how it should be represented, such as max/min length, type, defaults, etc. Depending on the logical context within the app I'm working on, a record (and thus its fields) can have multiple representations: row in a table, complete record as a table, abbreviated record as a table, complete form as table, form as row in a table, form with mandatory fields only, records have to be printed out as ini-files, etc. Unfortunately, it's not me making this stuff up, it's fixed requirements. At field level, there are also different possible representations. For example, I would like to be able to represent a record as a tabular form, with every input field being shown with its preferred length. In addition to this, I would like to have a different form with a fixed with multi-column layout; for this form, no input
[Lift] A gap in my knowledge, JsCommands
I'm wading into an area that I'm a bit unfamiliar with and not sure if
I'm running in a bug.
Snippet code:
class HelloWorld {
def ajaxFunc1() : JsCmd = JsRaw(alert('Button1 clicked'))
def ajaxFunc2(str: String) : JsCmd = {
Log.info(Received + str)
JsRaw(alert('Button2 clicked'))
}
def renderAjaxButtons(xhtml: NodeSeq): NodeSeq = {
bind(ex, xhtml,
button1 - SHtml.ajaxButton(Press Me, ajaxFunc1 _),
button2 - buttonPress Me 2/button % (onclick -
SHtml.ajaxCall(Str(Button-2), ajaxFunc2 _)))
}
}
Which is in this template:
lift:HelloWorld.renderAjaxButtons
ex:button1 /br /
ex:button2 /br /
/lift:HelloWorld.renderAjaxButtons
And is rendered thusly:
button onclick=lift_ajaxHandler('F687305521434PIG=true', null,
null); return false;Press Me/buttonbr /
button onclick=(F687305521435R3K,lift_ajaxHandler
('F687305521435R3K=' + 'Button-2', null, null))Press Me 2/
buttonbr /
Button 1 is find, but Button 2 causes FireBug to whine:
F687305521435R3K is not defined
onclick(click clientX=500, clientY=239)2 (line 2)
[Break on this error] F687305521435R3K,
lift_ajaxHandl...F687305521435R3K=Button-2, null, null);
Does the second onclick look incorrect to you?
--~--~-~--~~~---~--~~
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: HTML 5 Web Sockets ?
On Tue, Mar 31, 2009 at 2:35 AM, Matthias Wessendorf mwessend...@gmail.comwrote: Hi, I wonder if Lift does support HTML 5's Web Sockets. I think that I read it somewhere ... Lift 1.1 will support Web Sockets. I'm working with the Kaazing folks to make sure things work well with their server as well. The support will be invisible to your apps. If you're running in an HTML 5 browser and have a server that supports Web Sockets, Lift will take advantage of it, otherwise it will use the long polling that it currently does. Thanks! Matthias -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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] Re: Forms validation formatter
On Mar 31, 5:06 pm, Clemens Oertel clemens.oer...@gmail.com wrote: Hello, Sorry for the delay in my response, but I only get to play with lift on the weekends, and I wanted to look into your suggestions in more detail. I ported the toForm code from Record to Mapper (and by port, I mean mostly cut'n'paste). While doing so, I noticed 2 things: - Why not provide the same template mechanism used for forms for HTML output? This way I can reuse the same template for both - given that my records have at least dozens, if not even hundreds, of fields, that'd be a great help. Well you can load templates from an html file. Please see LiftSession.findAnyTemplate function. - The templates require the use of lift:field and similar tags. I thought I'd be really smart, and created a HTML file A with lift-tags (lift:SomeClass.add.../lift:SomeClass.add) to run my snippet, and used the lift:field tags as children to lift:SomeClass.add. This way, I can create my templates externally, and use the normal lift dispatch-from-view mechanism. And, to save me some more work, the actual form template is in a separate, reusable, HTML file B, to be embedded into A. Embedding, of course, requires eager evaluation. Fine. No. With eager evaluation, lift of course complains that there is no class field, as referenced by lift:field. Now me's wondering whether a separate namespace would be more appropriate? (I did switch to a different namespace, liftf, out of necessity, but I figure that other people might have similar issues) Well I can understand the urge but we do NOT recommend processing templates outside of rendering pipeline. You can call LiftSession.processSurroundAndInclude so that lift tags to be processed etc. but again it is not recommended. The main reason is that your functions that you assume to be bounded during this off- cycle template processing, will not actually be bounded cause it i happening in the wrong place. The Record's form template is to allow you to shape the form in any way you like (from markup perspective). But this template is supposed to be very very lightweight in terms of lift's tags. It is just an xhtml fragment and not a full blow page/(lift template). As to the original discussion: I still strongly believe that toForm and to/as(X)Html should not be in Mapper/Record. Different story for JSON/XML/SQL - those seem to me to be rather functionality complete, no problem. But form and html creation seem to be something that most users will want to adapt to their application's needs eventually - state dependent css classes, javascript validation, AJAX form updates... In the examples that I've seen so far, this functionality was dealt with in the snippet. So, either mapper/record eventually become this super- omnipotent-mega-classes that can deal with this functionality to (field.toJavaScriptValidatingAndIncrementallyAjaxUpdatingForm ...), or form/html generation happens in multiple locations, or the user has to override some functions from mapper/record/fields. My beef with this is A) that the respective function calls, given their current signature, require the respective mapper/record-objects to be fully aware of application state for more complex applications; and B) that it is my understanding that overriding internal classes of a framework is a bad thing - I'd rather see a proper application of the Hollywood principle. Just wanted to provide an outsider's feedback. Overall, I think lift's just fantastic. I'm really glad you like Lift ! Thank you for listening/reading, Clemens On 19-Mar-09, at 1:08 PM, marius d. wrote: On Mar 18, 11:24 pm, Clemens clemens.oer...@gmail.com wrote: Thank you for your patience, Marius. Well you can use different RecordMeta implementations if you need to different representation of a record without sequential template change. So no state dependency. , b I'm really not trying to be difficultut having multiple RecordMeta instances, for which the HTML output seems to be only one of many functionalities, seems to be shooting with canons at sparrows. Having a toForm functions that takes some template provider as input could be one option. Well this is kinda already in there but it's private :) ... See: private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq so to me makes sense to relax it ... to public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq ... thanks for reminding me about this :) Anyways, I was not even thinking at record level, but rather at field level. See below. Well keeping close view representation and backend abstraction makes a lot of sense as it reduces lots of complexity. Having records/ mappers that know how to represent themselves in different contexts (DB, xhtml) brings a lot of benefits an simplicity. I admit thought that (Btw, by
[Lift] SessionVar or RequestVar example
Does anyone know where I could find some example code of SessionVar or RequestVar in use? I am writing an application and I need to use a SessionVar or a RequestVar so that I can maintain and update the value of a variable throughout a session, but since I'm new to Lift I'm not sure how to use these types. Thanks, David --~--~-~--~~~---~--~~ 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: Forms validation formatter
Marius:
On 31-Mar-09, at 12:31 PM, marius d. wrote:
On Mar 31, 5:06 pm, Clemens Oertel clemens.oer...@gmail.com wrote:
- Why not provide the same template mechanism used for forms for HTML
output? This way I can reuse the same template for both - given that
my records have at least dozens, if not even hundreds, of fields,
that'd be a great help.
Well you can load templates from an html file. Please see
LiftSession.findAnyTemplate function.
just thought that, since MetaRecord has
def toForm(inst: BaseRecord): NodeSeq
and
def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq
it would only be consistent to provide similar means for HTML output.
Well I can understand the urge but we do NOT recommend processing
templates outside of rendering pipeline. You can call
LiftSession.processSurroundAndInclude so that lift tags to be
processed etc. but again it is not recommended. The main reason is
that your functions that you assume to be bounded during this off-
cycle template processing, will not actually be bounded cause it i
happening in the wrong place.
The Record's form template is to allow you to shape the form in any
way you like (from markup perspective). But this template is supposed
to be very very lightweight in terms of lift's tags. It is just an
xhtml fragment and not a full blow page/(lift template).
Mmh, maybe there's a misunderstanding. I was only using the template
as indicated in the source code, or so I thought.
May I just provide an abbreviated version of the code that I come up
with?
Outer Template
lift:surround with=default at=content
h2Create a New Site/h2
lift:snippet type=SiteOps.add form=post eager_eval=true
table
tfoot
tr
td colspan=3site:submitSubmit/site:submit/td
/tr
/tfoot
lift:embed what=/sites/_site /
/table
/lift:snippet
/lift:surround
End Outer Template
Embedded Template
tbody
tr
tdliftf:field_label name=nameName/liftf:field_label:/td
tdliftf:field name=nameA Hospital Site/liftf:field/td
tdliftf:field_msg name=name //td
/tr
/tbody
End Embedded Template
SiteOps
def add(form: NodeSeq): NodeSeq = {
val invokedAs = S.invokedAs
val site = Site.create
def newSite(form: NodeSeq): NodeSeq = {
def saveMe(): Unit = {
site.validate match {
case Nil = site.save ; S.notice(Added + site.name);
S.redirectTo(/sites/)
case xs = S.error(xs) ; S.mapSnippet(invokedAs, newSite)
}
}
bind(site, Site.toForm(site, form), submit -
submit(Save, saveMe))
}
newSite(form)
}
End SiteOps
The Site.toForm function is pretty much the same as found in
MetaRecord. It will eventually call each fields' toForm function
(which are the original Lift 1.0 mapper versions, no changes there).
Am I really doing things outside the rendering pipeline (this is not a
rhetorical question)? It all seems to work, incl. validation.
Also, the eagerly evaluated template, which will be passed to toForm,
contains only field tags, no other lift tags.
Again, imagine a few dozen different entities, each with a ton of
fields. I'm sure you'll understand that I'm hesitant to bind each
field manually (once for the list page, once for the display page,
once for the add page, and again once for the edit page, even though
the last 2 can surely be combined into one bind call in the code).
I obviously have to declare each field in the model, and refer to it
in the view. I really wouldn't mind not having to mention it anywhere
inbetween.
Thank you for all your help,
Clemens
Clemens Oertel
clem...@oertel.ca
--~--~-~--~~~---~--~~
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] MappedDateTime - Do we have a Date? Or is it a timestamp?
While trying to figure out why my MappedDateTime fields get stored in the DB with all the time info set to 0, I noticed the following: MappedDateTime (v. 1.0) claims to be a TimeStamp: def targetSQLType = Types.TIMESTAMP. However, it uses java.sql.Date for its JDBC- friendly converted version, not java.sql.TimeStamp. If I read the java.sql.Date documentation correctly, java.sql.Date does set all time information to 0, since the SQL DATE type only stores dates, by no times. Any comment whether this might have something to do with me losing my time would be appreciated. Best, Clemens --~--~-~--~~~---~--~~ 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: MappedDateTime - Do we have a Date? Or is it a timestamp?
I was on IRC trying to help Clemens with this. The name (MappedDateTime), targetSQLType (java.sql.Types.TIMESTAMP), and type (extends MappedField[java.util.Date, _]) of this class suggests millisecond precision (java.sql.Timestamp and java.util.Date have millisecond precision). However, methods jdbcFriendly and real_convertToJDBCFriendly use java.sql.Date, which has only day precision. If the intent is day precision, then calling the class DateTime is probably misleading. If the intent is millisecond precision, then we have a bug. rant Which brings up the larger issue of the brokennes of the Java Date/Time API. Java 7 will hopefully be getting a newer/better one, but for those of us stuck on Java 5/6, Joda Time is much preferable to the native Date/Time API. It more clearly represents foundational concepts like instants (March 31, 2009 at 12:15.000pm UTC), partials (March 3 or 7:15pm), intervals (the space between two instants), durations (1000 milliseconds), periods (1 month), and chronologies (calendar systems). It's also completely immutable (oh, you didn't know java.util.Calendar isn't thread-safe? you're lucky to have never had to track down that bug). /rant Sigh... it's probably too big of a breaking change to rip out Java Date/Time from Mapper and Helpers and replace it with Joda Time, but one can dream... --j On Tue, Mar 31, 2009 at 11:58 AM, Clemens Oertel clemens.oer...@gmail.comwrote: While trying to figure out why my MappedDateTime fields get stored in the DB with all the time info set to 0, I noticed the following: MappedDateTime (v. 1.0) claims to be a TimeStamp: def targetSQLType = Types.TIMESTAMP. However, it uses java.sql.Date for its JDBC- friendly converted version, not java.sql.TimeStamp. If I read the java.sql.Date documentation correctly, java.sql.Date does set all time information to 0, since the SQL DATE type only stores dates, by no times. Any comment whether this might have something to do with me losing my time would be appreciated. Best, Clemens --~--~-~--~~~---~--~~ 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: MappedDateTime - Do we have a Date? Or is it a timestamp?
For an internal project I used JodaTime, twas a dream. I have switched to using MappedLong along with Unix time for dates now. ( hooray for ancedotes! ) On Mar 31, 3:21 pm, Jorge Ortiz jorge.or...@gmail.com wrote: I was on IRC trying to help Clemens with this. The name (MappedDateTime), targetSQLType (java.sql.Types.TIMESTAMP), and type (extends MappedField[java.util.Date, _]) of this class suggests millisecond precision (java.sql.Timestamp and java.util.Date have millisecond precision). However, methods jdbcFriendly and real_convertToJDBCFriendly use java.sql.Date, which has only day precision. If the intent is day precision, then calling the class DateTime is probably misleading. If the intent is millisecond precision, then we have a bug. rant Which brings up the larger issue of the brokennes of the Java Date/Time API. Java 7 will hopefully be getting a newer/better one, but for those of us stuck on Java 5/6, Joda Time is much preferable to the native Date/Time API. It more clearly represents foundational concepts like instants (March 31, 2009 at 12:15.000pm UTC), partials (March 3 or 7:15pm), intervals (the space between two instants), durations (1000 milliseconds), periods (1 month), and chronologies (calendar systems). It's also completely immutable (oh, you didn't know java.util.Calendar isn't thread-safe? you're lucky to have never had to track down that bug). /rant Sigh... it's probably too big of a breaking change to rip out Java Date/Time from Mapper and Helpers and replace it with Joda Time, but one can dream... --j On Tue, Mar 31, 2009 at 11:58 AM, Clemens Oertel clemens.oer...@gmail.comwrote: While trying to figure out why my MappedDateTime fields get stored in the DB with all the time info set to 0, I noticed the following: MappedDateTime (v. 1.0) claims to be a TimeStamp: def targetSQLType = Types.TIMESTAMP. However, it uses java.sql.Date for its JDBC- friendly converted version, not java.sql.TimeStamp. If I read the java.sql.Date documentation correctly, java.sql.Date does set all time information to 0, since the SQL DATE type only stores dates, by no times. Any comment whether this might have something to do with me losing my time would be appreciated. Best, Clemens --~--~-~--~~~---~--~~ 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: Forms validation formatter
On Mar 31, 9:09 pm, Clemens Oertel clemens.oer...@gmail.com wrote:
Marius:
On 31-Mar-09, at 12:31 PM, marius d. wrote:
On Mar 31, 5:06 pm, Clemens Oertel clemens.oer...@gmail.com wrote:
- Why not provide the same template mechanism used for forms for HTML
output? This way I can reuse the same template for both - given that
my records have at least dozens, if not even hundreds, of fields,
that'd be a great help.
Well you can load templates from an html file. Please see
LiftSession.findAnyTemplate function.
just thought that, since MetaRecord has
def toForm(inst: BaseRecord): NodeSeq
and
def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq
it would only be consistent to provide similar means for HTML output.
Well I can understand the urge but we do NOT recommend processing
templates outside of rendering pipeline. You can call
LiftSession.processSurroundAndInclude so that lift tags to be
processed etc. but again it is not recommended. The main reason is
that your functions that you assume to be bounded during this off-
cycle template processing, will not actually be bounded cause it i
happening in the wrong place.
The Record's form template is to allow you to shape the form in any
way you like (from markup perspective). But this template is supposed
to be very very lightweight in terms of lift's tags. It is just an
xhtml fragment and not a full blow page/(lift template).
Mmh, maybe there's a misunderstanding. I was only using the template
as indicated in the source code, or so I thought.
May I just provide an abbreviated version of the code that I come up
with?
Outer Template
lift:surround with=default at=content
h2Create a New Site/h2
lift:snippet type=SiteOps.add form=post eager_eval=true
table
tfoot
tr
td colspan=3site:submitSubmit/site:submit/td
/tr
/tfoot
lift:embed what=/sites/_site /
/table
/lift:snippet
/lift:surround
End Outer Template
Embedded Template
tbody
tr
tdliftf:field_label name=nameName/liftf:field_label:/td
tdliftf:field name=nameA Hospital Site/liftf:field/td
tdliftf:field_msg name=name //td
/tr
/tbody
End Embedded Template
SiteOps
def add(form: NodeSeq): NodeSeq = {
val invokedAs = S.invokedAs
val site = Site.create
def newSite(form: NodeSeq): NodeSeq = {
def saveMe(): Unit = {
site.validate match {
case Nil = site.save ; S.notice(Added + site.name);
S.redirectTo(/sites/)
case xs = S.error(xs) ; S.mapSnippet(invokedAs, newSite)
}
}
bind(site, Site.toForm(site, form), submit -
submit(Save, saveMe))
}
newSite(form)
}
End SiteOps
The Site.toForm function is pretty much the same as found in
MetaRecord. It will eventually call each fields' toForm function
(which are the original Lift 1.0 mapper versions, no changes there).
Am I really doing things outside the rendering pipeline (this is not a
rhetorical question)?
Nope sorry ... I misunderstood your case. By bad entirely.
It all seems to work, incl. validation.
Also, the eagerly evaluated template, which will be passed to toForm,
contains only field tags, no other lift tags.
Again, imagine a few dozen different entities, each with a ton of
fields. I'm sure you'll understand that I'm hesitant to bind each
field manually (once for the list page, once for the display page,
once for the add page, and again once for the edit page, even though
the last 2 can surely be combined into one bind call in the code).
I obviously have to declare each field in the model, and refer to it
in the view. I really wouldn't mind not having to mention it anywhere
inbetween.
This is actually a nice thing to do. Sorry that I misunderstood your
intentions :)
Thank you for all your help,
Clemens
Clemens Oertel
clem...@oertel.ca
--~--~-~--~~~---~--~~
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: Menu widget
I would like to use this new MenuWidget, so I got the source code from
GitHub and put it into my application as a snippet. I also downloaded
all of the necessary superfish .css and .js files from the superfish
website and put those in local sub-directories of the src/main/
webapp folder. When I try to compile the code in maven, however, I
get the following error.
C:\Source\trunk\eclipse\testLiftmvn clean jetty:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO]
[INFO] Building testLift
[INFO]task-segment: [clean, jetty:run]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory C:\Source\trunk\eclipse\testLift\target
[INFO] Preparing jetty:run
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [yuicompressor:compress {execution: default}]
[INFO] jquery.hoverIntent.js (4637b) - jquery.hoverIntent.js (0b)[0%]
[INFO] superfish.js (3837b) - superfish.js (0b)[0%]
[INFO] entryform.css (11417b) - entryform.css (10202b)[89%]
[INFO] print.css (1341b) - print.css (821b)[61%]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Illegal group reference
[INFO]
[INFO] Trace
java.lang.IllegalArgumentException: Illegal group reference
at java.util.regex.Matcher.appendReplacement(Matcher.java:713)
at com.yahoo.platform.yui.compressor.CssCompressor.compress
(CssCompresso
r.java:78)
at
net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile(YuiCom
pressorMojo.java:182)
at net.sf.alchim.mojo.yuicompressor.MojoSupport.processDir
(MojoSupport.j
ava:151)
at net.sf.alchim.mojo.yuicompressor.MojoSupport.execute
(MojoSupport.java
:105)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPlugi
nManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecy
cle(DefaultLifecycleExecutor.java:924)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(Def
aultLifecycleExecutor.java:767)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
Goal(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:482)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:291)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLi
fecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:
336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:
129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced
(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode
(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Tue Mar 31 17:38:35 EDT 2009
[INFO] Final Memory: 17M/30M
[INFO]
Any ideas on how to prevent/fix this? Do I need to modify my .pom?
Thanks,
David
On Mar 23, 12:18 pm, marius d. marius.dan...@gmail.com wrote:
Cool ... if you tested it and theMenuWidget, from my perspective it
is good to go into master. And it's really great that you added the
ScalaDocs !!!
Br's,
Marius
On Mar 23, 6:07 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
OK, I've pushed the new code on the wip-dcb-dropdown branch. I made some
minor mods to the builtin Menu snippet (and changes to the Menu widget to
match):
1. Added an expandAll attribute
[Lift] Re: SessionVar or RequestVar example
I figured out what I needed by checking out the counting link on the Lift demo page. However, I'd like to see some more examples of Session or RequestVar in use, so if anyone has some I'd still appreciate it. On Mar 31, 12:44 pm, DavidV david.v.villa...@gmail.com wrote: Does anyone know where I could find some example code of SessionVar or RequestVar in use? I am writing an application and I need to use a SessionVar or a RequestVar so that I can maintain and update the value of a variable throughout a session, but since I'm new to Lift I'm not sure how to use these types. Thanks, David --~--~-~--~~~---~--~~ 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: SessionVar or RequestVar example
Check out the JPA example, that has some neat use of hooking JPA into lifts RequestVar On Mar 31, 10:49 pm, DavidV david.v.villa...@gmail.com wrote: I figured out what I needed by checking out the counting link on the Lift demo page. However, I'd like to see some more examples of Session or RequestVar in use, so if anyone has some I'd still appreciate it. On Mar 31, 12:44 pm, DavidV david.v.villa...@gmail.com wrote: Does anyone know where I could find some example code of SessionVar or RequestVar in use? I am writing an application and I need to use a SessionVar or a RequestVar so that I can maintain and update the value of a variable throughout a session, but since I'm new to Lift I'm not sure how to use these types. Thanks, David --~--~-~--~~~---~--~~ 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: MappedDateTime - Do we have a Date? Or is it a timestamp?
chronologies (calendar systems). It's also completely immutable (oh, you didn't know java.util.Calendar isn't thread-safe? you're lucky to have never had to track down that bug). LOL!!! Its not thread safe!? Thats somewhat of an oversight isnt it... --~--~-~--~~~---~--~~ 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: lift:Menu.group
So, how would I test this function in specs? I would need to create a
mock object of S, right?
Thanks,
Bradford
On Mar 29, 8:02 pm, bradford fingerm...@gmail.com wrote:
This can probably be improved (and I've done little testing on it),
but I've come up with something to satisfy my description above:
def group(template: NodeSeq): NodeSeq = {
val default = S.attr(default).openOr()
val active_attrs = S.prefixedAttrsToMetaData(active)
val names = template \\ bind filter(_.prefix == menu)
flatMap(_.attributes.get(name))
def bind(xml: NodeSeq, currentPage: String): NodeSeq = {
xml.flatMap {
node = node match {
case s : Elem if (node.prefix == menu
node.label == bind) = {
node.attributes.get(name) match {
case None = bind(node.child,
currentPage)
case Some(ns) = {
SiteMap.findLoc(ns.text) match
{
case Full(location) =
val link: Elem = a
href={location.createDefaultLink}{location.linkText.openOr()}/a //
location.createDefaultLink.toList.firstOption.getOrElse(a
/).asInstanceOf[Elem]
if (ns == currentPage)
link %
anchorAttributes(node.attributes) % active_attrs
else
link %
anchorAttributes(node.attributes)
case _ = bind
(node.child, currentPage)
}
}
}
}
case Group(nodes) = Group(bind(nodes,
currentPage))
case s : Elem = Elem(node.prefix, node.label,
node.attributes,node.scope, bind(node.child, currentPage) : _*)
case n = node
}
}
}
for (request - S.request.toList;
loc - request.location.toList)
yield {
val currentPage: String = if (names.contains(loc.name))
loc.name else default
println(currentPage + currentPage)
Group(bind(template, currentPage))
}
}
private def anchorAttributes(attributes : MetaData) : MetaData = {
val amap = Map() ++ attributes.flatMap(attr = attr match {
case ua : PrefixedAttribute =
ua.pre match {
case a = List(ua.key -
ua.value.first.toString)
case _ = Nil
}
case _ = Nil
})
S.mapToAttrs(amap)
}
On Mar 28, 11:59 am, bradford fingerm...@gmail.com wrote:
Hi Derek,
Cool. I will still use your changes, but for this task I will need
what I have described above. This will give me the ability to set
attributes to the selected item or default to a selected item if
there is no match. For example, let's say I have archives, music, and
movies. If I am on music, I want to set a selected class or style on
it. But if I embed movies into home, there will be no matches so I
want it to default to movies.
Thanks for your help and work,
Bradford
On Mar 28, 11:53 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
Argh, stupid mistake on not capturing attrs. I'm pushing a fix up to git
in
about 10 minutes. With this fix, is there still a reason that you need to
build your own MyMenu.group snippet?
Derek
On Fri, Mar 27, 2009 at 7:02 PM, bradford fingerm...@gmail.com wrote:
Derek, I saw the changes and noticed that it doesn't capture the a
attributes anymore. I just wanted to point it out, because I wasn't
sure if that was intended or not.
Ok, I finally came up with a design for what I'm looking for:
lift:MyMenu.group active:class=selected default=home
limenu:bind name=home a:id=home //li
limenu:bind name=archives a:id=archives //li
limenu:bind name=music a:id=music a:style=margin-left:
10px; //li
/lift:MyMenu.group
I originally was going to try menu:home / and menu:archives /
instead since I could probably just call bind straight up on them, but
I couldn't figure out how to extract these sub-elements since they are
prefixed.
Regards,
Bradford
On Mar 27, 1:57 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
It's in trunk now. Add the donthide attribute to your Menu.item tags
and
you'll get the same text as you would normally, just not in link form.
Derek
On Wed, Mar 25, 2009 at 4:31 PM, bradford fingerm...@gmail.com
wrote:
Derek, that'll work :)
Thanks,
Bradford
[Lift] autocomplete - options
The autocomplete widget is very cool, but I can't figure out how to use it to change some of the JQuery autocomplete options such as the delay and minChars. Also, how could I modify the JQuery autocomplete result handler? Thanks, Bradford --~--~-~--~~~---~--~~ 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: MappedDateTime - Do we have a Date? Or is it a timestamp?
I'm also using joda-time, and very pleased with it. In fact, I use it in my Lift project - via JPA with the provided Hibernate extensions for mapping of DateTime, Period, etc. Kris On Tue, Mar 31, 2009 at 1:54 PM, TylerWeir tyler.w...@gmail.com wrote: For an internal project I used JodaTime, twas a dream. I have switched to using MappedLong along with Unix time for dates now. ( hooray for ancedotes! ) On Mar 31, 3:21 pm, Jorge Ortiz jorge.or...@gmail.com wrote: I was on IRC trying to help Clemens with this. The name (MappedDateTime), targetSQLType (java.sql.Types.TIMESTAMP), and type (extends MappedField[java.util.Date, _]) of this class suggests millisecond precision (java.sql.Timestamp and java.util.Date have millisecond precision). However, methods jdbcFriendly and real_convertToJDBCFriendly use java.sql.Date, which has only day precision. If the intent is day precision, then calling the class DateTime is probably misleading. If the intent is millisecond precision, then we have a bug. rant Which brings up the larger issue of the brokennes of the Java Date/Time API. Java 7 will hopefully be getting a newer/better one, but for those of us stuck on Java 5/6, Joda Time is much preferable to the native Date/Time API. It more clearly represents foundational concepts like instants (March 31, 2009 at 12:15.000pm UTC), partials (March 3 or 7:15pm), intervals (the space between two instants), durations (1000 milliseconds), periods (1 month), and chronologies (calendar systems). It's also completely immutable (oh, you didn't know java.util.Calendar isn't thread-safe? you're lucky to have never had to track down that bug). /rant Sigh... it's probably too big of a breaking change to rip out Java Date/Time from Mapper and Helpers and replace it with Joda Time, but one can dream... --j On Tue, Mar 31, 2009 at 11:58 AM, Clemens Oertel clemens.oer...@gmail.comwrote: While trying to figure out why my MappedDateTime fields get stored in the DB with all the time info set to 0, I noticed the following: MappedDateTime (v. 1.0) claims to be a TimeStamp: def targetSQLType = Types.TIMESTAMP. However, it uses java.sql.Date for its JDBC- friendly converted version, not java.sql.TimeStamp. If I read the java.sql.Date documentation correctly, java.sql.Date does set all time information to 0, since the SQL DATE type only stores dates, by no times. Any comment whether this might have something to do with me losing my time would be appreciated. Best, Clemens --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
