Re: [Lift] Comet shutdown?
Hello, > A CometActor has a lifespan of the session, not a particular page. The same > component may be visible on many different pages. The same component may > receive messages from external source, even when the component is not being > displayed. The CometActor is a much more pure (in the Smalltalk sense) > implementation of MVC than anything else on the web. Ah, I see. Makes sense :) But still I would like to make the actor more short-lived then the session (which lives now 30 minutes I think). > If you want a CometActor to shut down if it has not appeared on any page for > a certain period of time, you can override timespan = Full(2 minutes) in the > CometActor. unfortunately there's no "timespan" method in CometActor (nor any other method with the word "time" in it - I looked before I posted :) ). So is there a way to make the actor live shorter then the session? -- Thanks, Adam Warski http://www.warski.org http://www.softwaremill.eu -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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] Idea proposal for Google Summer of Code project
Morning everyone (it's 8am in Denmark) I would very much like to participate in Google Summer of Code 2010. I know I'm eligible to participate because I'm a student at the IT University of Copenhagen and I'm pretty sure Lift is eligible to participate as a mentoring organization - So all we need now is an 'Ideas-list' which is a list of potential projects for the students to work on created by the mentoring organization. Here's my proposal for an idea to the 'ideas-list' - one I would like to work on :) The idea: -- A graphical tool to help people with the data-model part of a Lift project. The user would be able to draw UML models with a simple tool which would be coded by the student - once the user has drawn a few classes it would have the ability to export an XML file. A small scala application would read the XML file and output the correct mapper/ record classes. The tool should be able to read existing classes and discover any changes so it could be reflected in the graphical representation. So basically it would be like Core Data just for Lift ;) It would make sense to code the graphical tool for the browser - possible with the very potent mix og jQuery and Raphaël (http:// raphaeljs.com/) -- So what do you think, is it something you would want to use? Thanks, Mads Hartmann Jensen -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Helpers.bind question
Thanks guys. It works.
On Feb 9, 2010, at 10:26 PM, David Pollak wrote:
>
>
> On Tue, Feb 9, 2010 at 12:04 PM, GA wrote:
> What we have here is a iphone native application that has the help screens in
> HTML. The help screens are in multiple languages and are stored in the
> database.
>
> When the application starts, it checks in the server for updates in the help
> pages calling a particular URL but with different context parameters. The
> downloaded HTML is stored locally in the app to be able to work when the
> phone is offline. The downloaded content has a common template for each
> language and it loads the content from the database.
>
> The help content has been written as HTML in MS Word. It has been already
> formatted there. That is why it is stored altogether in the database. It is
> not a typical lift web site.
>
> If it is not possible to pass the characters unescaped, then we will have to
> create the pages individually loading just the text from the database. It is
> not a big deal and I know it would be cleaner, but I wanted to know if we can
> avoid this change.
>
> As Naftoli mentioned, scala.xml.Unparsed(string) will pass string to the
> output. If the string is not valid XML, the client browser may complain.
>
>
> Thanks in advance,
>
> GA
>
> On Feb 9, 2010, at 8:31 PM, David Pollak wrote:
>
>>
>>
>> On Tue, Feb 9, 2010 at 10:00 AM, GA wrote:
>> Hello guys,
>>
>> I have a very silly question. I have a snippet that reads a string field
>> from the database and it inserts it within a html page.
>>
>> So far so good. The text that the snippet reads from the database is a piece
>> of html code. The problem is that the bind method replaces the "<" and ">"
>> within the string with "<" and ">". The snippet looks like that:
>>
>> if (context != "") {
>> ContextHelp.findByKey(context.toLong) match {
>> case Full(help) => {
>> val message = help.contextHelp
>> Helpers.bind("b", in, "text" -> message.toString)
>> }
>> case _ => Helpers.bind("b", in, "text" -> "Context not
>> found")
>> }
>> } else Helpers.bind("b", in, "text" -> "The URL is invalid. ")
>>
>>
>> The HTML that calls the snippet looks like this:
>>
>>
>>
>>
>>
>> What should I do to get the html content without changes in the tags?
>>
>> It is not Helpers.bind() that's transforming the text. It's the XML
>> libraries that properly XML escape Text() elements when they are converted
>> from XML representation to a byte stream.
>>
>> In almost every context, this is what you want... you want Strings to be
>> properly escaped. If that was not the case, there would be tons of cross
>> site scripting issues.
>>
>> So, what is the type of "message" in the code above? Do you really, really,
>> really mean for the String representation of message to be not XML escaped?
>>
>>
>> Thanks in advance,
>>
>> GA
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@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.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from
Re: [Lift] Re: Snippet with no reflection an no massive case statement
Besides, would it even help? Is the time in obtaining a Method instance rather than invoking it? - David Pollak wrote: On Tue, Feb 9, 2010 at 9:10 AM, Hugo Palma wrote: > Why doesn't Lift create the mapping at startup using reflection ? > It's not using reflection that's the problem, it's using reflection at > runtime for every single snippet usage. > Why do you care? The cost of doing a method dispatch via reflection is about 5x the cost of a doing a method call on an interface with is about 2x more costly than doing a method call on a class. The amount of time to do reflection on the 10 or 20 snippets you may have on a page is unmeasurably small compared to the cost of rendering the page. > > I may be over simplifying things, but if at startup Lift would go > through all snippet classes and using reflection found all the methods > kept all the mappings somewhere in memory i think it could work. > Is this doable ? > No, it is not possible at start-up time to determine all the classes that might be snippets. > > On 9 Fev, 17:01, Timothy Perrett wrote: > > So you don't want to write any explicit mapping, and you don't want to > use reflection??? How would you propose Lift know what your asking for? > > > > Im afraid voodoo is not yet compatible with the JVM ;-) > > > > Cheers, Tim > > > > On 9 Feb 2010, at 16:54, Hugo Palma wrote: > > > > > > > > > I just readhttp://wiki.github.com/dpp/liftweb/about-snippetsand i > > > have the following question: > > > > > So is really the only way to avoid having a reflection call every time > > > you use a snippet to use a DispatchSnippet with a case statement for > > > every method ? > > > It's just that i don't really think that the case is a very clean way > > > of doing things. Can be ok for a couple of methods but it can be > > > really ugly with more than that. > > > > > So, is there any other way ? > > > Thanks. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Lift" group. > > > To post to this group, send email to lift...@googlegroups.com. > > > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > > > For more options, visit this group athttp:// > groups.google.com/group/liftweb?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Support for page and snippet level localization
If the same snippet is used by two pages you would want two separate resource bundles to be used for the same snippet? - Hugo Palma wrote: So what you're saying is that a page can include a bunch of snippets and that's why it doesn't be an advantage to have page resource bundles ? I'm sorry but i don't see why. I'm not sure how people are using resource bundles with Lift now but the way i would do it would be to create a resource bundle for each page that would have the properties that are specific to that page and then i would have one or more bundles with properties that would be used in several pages across the application. I think this makes sense in large applications because it's just a natural way of organizing your translated text. I realize this is possible with Lift now, but it has the following problems: - Even if you separate in bundles the properties are globally available. There's no bundle "namespace" concept. For example, i might want to have the property page-name with the current page name. And if i'm on the home page i want it to translate to "Home" and if i'm on the search page i want it to translate to "Search". This could be possible with this. - I have to register every single resource bundle in LiftRules.resourceNames. Although not critical this could easily be replace with automatic bindle discovery like i suggested. On Tue, Feb 9, 2010 at 17:38, Timothy Perrett wrote: > The analogy would be MVC controllers... the index method has an index > page and an index resource bundle. Within Lift, we dont use > controllers, so there is nothing stopping you calling a whole bunch of > snippets on a single page - thus, there would be no single "page" > resource bundle (that is, it wouldn't buy you anything IMHO) as > different snippets might share localised text or whatever. I guess im > just trying to say things are not silo'ed in Lift. > > Does that add some more clarity to my statement? > > Cheers, Tim > > On Feb 9, 2:47 pm, Hugo Palma wrote: > > Sorry Tim but i don't quite understand what you mean by "page is > > scoped to a single snippet" and that invalidates that you have a > > resource bundle per page. Sorry is this is clear to everyone else but > > i'm new with Lift so i'm still grasping basic concepts. > > > > On Feb 8, 10:49 pm, Timothy Perrett wrote: > > > > > > > > > That wouldn't work for Lift as it assumes a page is scoped to a single > snippet. It works with Tapestry because its an MVC framework. > > > > > Lift is *not* MVC. > > > > > Have you seen LiftRules.resourceBundleFactories ? > > > > > Cheers, Tim > > > > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: > > > > > > Lift only support global resource bundles, i think it would be very > > > > useful if page and snipped level resource bundles were supported. > > > > For example, if i have a page "index" it would automatically have > > > > access to the index.properties_ bundle. Obviously this bundle > > > > would not be accessible from any other page. > > > > > > I come from an Apache Tapestry background that has page and component > > > > level localization and it proved very useful. > > > > > > What do you guys think about this ? > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups "Lift" group. > > > > To post to this group, send email to lift...@googlegroups.com. > > > > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > > > > For more options, visit this group athttp:// > groups.google.com/group/liftweb?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Make MenuBuilder generate link for current page
linkToSelf="true"? (Without getting involved in the different conventions for multiple-word attributes :) ) - David Pollak wrote: On Mon, Feb 8, 2010 at 6:53 AM, Hugo Palma wrote: > By default the menubuilder snippet doesn't generate a link for the > current page. > Can this behavior be changed ? > There's currently no option to override this behavior. What attribute do folks think should be added to change this behavior? > > Thanks > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Why not SHtml?
Never mind, apparently I wasn't up to date. On Tue, Feb 9, 2010 at 11:20 PM, Naftoli Gugenheim wrote: > I got OneToMany to compile (not in a way that would work on 2.7 though). > Then I tried to push it: > naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh) > $ git rebase origin/280_port_refresh > Current branch 280_port_refresh is up to date. > > naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh) > $ git push origin 280_port_refresh > To g...@github.com:dpp/liftweb.git > ! [rejected]280_port_refresh -> 280_port_refresh (non-fast > forward) > error: failed to push some refs to 'g...@github.com:dpp/liftweb.git' > > naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh) > $ > > Actually I only did the rebase to be sure, after I had already gotten the > 'non-fast forward' error. What am I doing wrong? > > As far as ManyToMany, I can't work on it because the compiler seems to just > freeze (using up CPU though). I assume that means there's a compiler bug > involved. > > Thanks. > > > On Tue, Feb 9, 2010 at 5:46 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> >> >> On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim >> wrote: >> >>> Could you give me exact instructions what to do to test my code on 2.8? >> >> >> git checkout -b 280_port_refresh origin/280_port_refresh >> cd framework/lift-persistence/lift-mapper >> emacs $(grep -l "FIXME: 280" $(find . -name *.scala)) >> >> remove the comments around your code. Make it compile and pass the >> existing tests. >> >> >>> Thanks. >>> >>> 2010/2/7 David Pollak >>> On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim >>> > wrote: > So if I get around to it would it indeed be preferable to point it to > SHtml? > Changing the code is one of the lowest priorities I could imagine. I would say that closing the stuff you've had on review board for > 1 months would be much higher priority. Adding copyright notices and other headers to the code you've written in Lift is a higher priority. Helping to port your code to 2.8 would be a higher priority. > > - > David Pollak wrote: > > On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim < > naftoli...@gmail.com>wrote: > > > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly > > rather than using SHtml? Is it not duplicate code? > > > > Because the Mapper code was the earliest Lift code... written long > before > SHtml. > > > > Thanks. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Lift" group. > > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google > Groups "Lift" group. > To post to this group, send email to lift...@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. > > -- > > You received this message because you are subscribed to the Google > Groups "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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. >>>
Re: [Lift] Why not SHtml?
I got OneToMany to compile (not in a way that would work on 2.7 though). Then I tried to push it: naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh) $ git rebase origin/280_port_refresh Current branch 280_port_refresh is up to date. naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh) $ git push origin 280_port_refresh To g...@github.com:dpp/liftweb.git ! [rejected]280_port_refresh -> 280_port_refresh (non-fast forward) error: failed to push some refs to 'g...@github.com:dpp/liftweb.git' naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh) $ Actually I only did the rebase to be sure, after I had already gotten the 'non-fast forward' error. What am I doing wrong? As far as ManyToMany, I can't work on it because the compiler seems to just freeze (using up CPU though). I assume that means there's a compiler bug involved. Thanks. On Tue, Feb 9, 2010 at 5:46 PM, David Pollak wrote: > > > On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim wrote: > >> Could you give me exact instructions what to do to test my code on 2.8? > > > git checkout -b 280_port_refresh origin/280_port_refresh > cd framework/lift-persistence/lift-mapper > emacs $(grep -l "FIXME: 280" $(find . -name *.scala)) > > remove the comments around your code. Make it compile and pass the > existing tests. > > >> Thanks. >> >> 2010/2/7 David Pollak >> >>> >>> >>> On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim >>> wrote: >>> So if I get around to it would it indeed be preferable to point it to SHtml? >>> >>> Changing the code is one of the lowest priorities I could imagine. I >>> would say that closing the stuff you've had on review board for > 1 months >>> would be much higher priority. Adding copyright notices and other headers >>> to the code you've written in Lift is a higher priority. Helping to port >>> your code to 2.8 would be a higher priority. >>> >>> - David Pollak wrote: On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim < naftoli...@gmail.com>wrote: > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly > rather than using SHtml? Is it not duplicate code? > Because the Mapper code was the earliest Lift code... written long before SHtml. > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >>> Beginning Scala http://www.apress.com/book/view/1430219890 >>> Follow me: http://twitter.com/dpp >>> Surf the harmonics >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, se
Re: [Lift] CRUDify Customized Access Control Issues
On 9 February 2010 20:11, Jeppe Nejsum Madsen wrote: > Robert Thurnher writes: > >> On 9 February 2010 16:04, Jeppe Nejsum Madsen wrote: > > [...] > > I suggest you upgrade to 2.0-SNAPSHOT (or M1}, much improved :-) Am definitely going to give that a spin (wanted to get a better feel of Lift in general before it). BTW, how "safe" is it to use M* resp. SNAPSHOT releases? >>> >>> The milestones are fairly safe. I can only recall one that didn't work >>> as expected. Snapshots are mostly fine, with an occasional breakage. >>> >>> We're running SNAPSHOT on our production site and I can only recall a >>> few situations where deployment failed, and none where functionality >>> was compromised >> >> Thanks for info, good to know. >> Going to upgrade to 2.0-M1 (or at least the latest 1.1 one) ASAP. > > Don't use the 1.1 ones, there was a naming change 1.1 -> 2.0, so 2.0-M1 > is considered the best non 1.0.x release...(I'll even say the best > release :-) Alright, thanks for all that useful info for a Lift newbie. :) -- Robert -- http://soup.robert42.com/ -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Why not SHtml?
Thanks - David Pollak wrote: On Tue, Feb 9, 2010 at 2:49 PM, Naftoli Gugenheim wrote: > Sorry - what's the Windows (eclipse) equivalent--i.e., what does that line > do? > Find all the files that contain "FIXME: 280" in the mapper package. > Also I wasn't sure what you meant by 'comments around my code.' > It will become very obvious when you open the files. The entire contents of: ./src/test/scala/net/liftweb/mapper/ManyToManySpecs.scala ./src/main/scala/net/liftweb/mapper/ManyToMany.scala ./src/main/scala/net/liftweb/mapper/OneToMany.scala Are commented out. > Thanks! > > - > David Pollak wrote: > > On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim >wrote: > > > Could you give me exact instructions what to do to test my code on 2.8? > > > git checkout -b 280_port_refresh origin/280_port_refresh > cd framework/lift-persistence/lift-mapper > emacs $(grep -l "FIXME: 280" $(find . -name *.scala)) > > remove the comments around your code. Make it compile and pass the > existing > tests. > > > > Thanks. > > > > 2010/2/7 David Pollak > > > >> > >> > >> On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim >wrote: > >> > >>> So if I get around to it would it indeed be preferable to point it to > >>> SHtml? > >>> > >> > >> Changing the code is one of the lowest priorities I could imagine. I > >> would say that closing the stuff you've had on review board for > 1 > months > >> would be much higher priority. Adding copyright notices and other > headers > >> to the code you've written in Lift is a higher priority. Helping to > port > >> your code to 2.8 would be a higher priority. > >> > >> > >>> > >>> - > >>> David Pollak wrote: > >>> > >>> On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim < > naftoli...@gmail.com > >>> >wrote: > >>> > >>> > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly > >>> > rather than using SHtml? Is it not duplicate code? > >>> > > >>> > >>> Because the Mapper code was the earliest Lift code... written long > before > >>> SHtml. > >>> > >>> > >>> > Thanks. > >>> > > >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> Groups > >>> > "Lift" group. > >>> > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > >>> Beginning Scala http://www.apress.com/book/view/1430219890 > >>> Follow me: http://twitter.com/dpp > >>> Surf the harmonics > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Lift" group. > >>> To post to this group, send email to lift...@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. > >>> > >>> -- > >>> > >>> You received this message because you are subscribed to the Google > Groups > >>> "Lift" group. > >>> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > >> Beginning Scala http://www.apress.com/book/view/1430219890 > >> Follow me: http://twitter.com/dpp > >> Surf the harmonics > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Lift" group. > >> To post to this group, send email to lift...@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. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email
Re: [Lift] Mapped(Date)(Time) formatter/parser
At what would make sense to move around, i.e., what I should to move #257 and #258 forward. Thanks! - Jeppe Nejsum Madsen wrote: Naftoli Gugenheim writes: > It would be really great if you could take a look at TimeHelpers and my diff > (vs. original), on RB and wip-nafg-date. I'll be glad to take a look, but not really sure what it is you want me to look at :-) > I asked about your time zone only because I was wondering if you'd be around > when I pushed it, but it's pushed. Ok, it's getting late here but I'll look tomorrow... /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Why not SHtml?
Never mind, I go your intent. Thanks. - David Pollak wrote: On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim wrote: > Could you give me exact instructions what to do to test my code on 2.8? git checkout -b 280_port_refresh origin/280_port_refresh cd framework/lift-persistence/lift-mapper emacs $(grep -l "FIXME: 280" $(find . -name *.scala)) remove the comments around your code. Make it compile and pass the existing tests. > Thanks. > > 2010/2/7 David Pollak > >> >> >> On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim >> wrote: >> >>> So if I get around to it would it indeed be preferable to point it to >>> SHtml? >>> >> >> Changing the code is one of the lowest priorities I could imagine. I >> would say that closing the stuff you've had on review board for > 1 months >> would be much higher priority. Adding copyright notices and other headers >> to the code you've written in Lift is a higher priority. Helping to port >> your code to 2.8 would be a higher priority. >> >> >>> >>> - >>> David Pollak wrote: >>> >>> On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim >> >wrote: >>> >>> > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly >>> > rather than using SHtml? Is it not duplicate code? >>> > >>> >>> Because the Mapper code was the earliest Lift code... written long before >>> SHtml. >>> >>> >>> > Thanks. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Lift" group. >>> > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >>> Beginning Scala http://www.apress.com/book/view/1430219890 >>> Follow me: http://twitter.com/dpp >>> Surf the harmonics >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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. >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Surf the harmonics >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@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. >> > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Why not SHtml?
On Tue, Feb 9, 2010 at 2:49 PM, Naftoli Gugenheim wrote: > Sorry - what's the Windows (eclipse) equivalent--i.e., what does that line > do? > Find all the files that contain "FIXME: 280" in the mapper package. > Also I wasn't sure what you meant by 'comments around my code.' > It will become very obvious when you open the files. The entire contents of: ./src/test/scala/net/liftweb/mapper/ManyToManySpecs.scala ./src/main/scala/net/liftweb/mapper/ManyToMany.scala ./src/main/scala/net/liftweb/mapper/OneToMany.scala Are commented out. > Thanks! > > - > David Pollak wrote: > > On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim >wrote: > > > Could you give me exact instructions what to do to test my code on 2.8? > > > git checkout -b 280_port_refresh origin/280_port_refresh > cd framework/lift-persistence/lift-mapper > emacs $(grep -l "FIXME: 280" $(find . -name *.scala)) > > remove the comments around your code. Make it compile and pass the > existing > tests. > > > > Thanks. > > > > 2010/2/7 David Pollak > > > >> > >> > >> On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim >wrote: > >> > >>> So if I get around to it would it indeed be preferable to point it to > >>> SHtml? > >>> > >> > >> Changing the code is one of the lowest priorities I could imagine. I > >> would say that closing the stuff you've had on review board for > 1 > months > >> would be much higher priority. Adding copyright notices and other > headers > >> to the code you've written in Lift is a higher priority. Helping to > port > >> your code to 2.8 would be a higher priority. > >> > >> > >>> > >>> - > >>> David Pollak wrote: > >>> > >>> On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim < > naftoli...@gmail.com > >>> >wrote: > >>> > >>> > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly > >>> > rather than using SHtml? Is it not duplicate code? > >>> > > >>> > >>> Because the Mapper code was the earliest Lift code... written long > before > >>> SHtml. > >>> > >>> > >>> > Thanks. > >>> > > >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> Groups > >>> > "Lift" group. > >>> > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > >>> Beginning Scala http://www.apress.com/book/view/1430219890 > >>> Follow me: http://twitter.com/dpp > >>> Surf the harmonics > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Lift" group. > >>> To post to this group, send email to lift...@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. > >>> > >>> -- > >>> > >>> You received this message because you are subscribed to the Google > Groups > >>> "Lift" group. > >>> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > >> Beginning Scala http://www.apress.com/book/view/1430219890 > >> Follow me: http://twitter.com/dpp > >> Surf the harmonics > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Lift" group. > >> To post to this group, send email to lift...@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. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, v
Re: [Lift] Why not SHtml?
Sorry - what's the Windows (eclipse) equivalent--i.e., what does that line do? Also I wasn't sure what you meant by 'comments around my code.' Thanks! - David Pollak wrote: On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim wrote: > Could you give me exact instructions what to do to test my code on 2.8? git checkout -b 280_port_refresh origin/280_port_refresh cd framework/lift-persistence/lift-mapper emacs $(grep -l "FIXME: 280" $(find . -name *.scala)) remove the comments around your code. Make it compile and pass the existing tests. > Thanks. > > 2010/2/7 David Pollak > >> >> >> On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim >> wrote: >> >>> So if I get around to it would it indeed be preferable to point it to >>> SHtml? >>> >> >> Changing the code is one of the lowest priorities I could imagine. I >> would say that closing the stuff you've had on review board for > 1 months >> would be much higher priority. Adding copyright notices and other headers >> to the code you've written in Lift is a higher priority. Helping to port >> your code to 2.8 would be a higher priority. >> >> >>> >>> - >>> David Pollak wrote: >>> >>> On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim >> >wrote: >>> >>> > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly >>> > rather than using SHtml? Is it not duplicate code? >>> > >>> >>> Because the Mapper code was the earliest Lift code... written long before >>> SHtml. >>> >>> >>> > Thanks. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Lift" group. >>> > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >>> Beginning Scala http://www.apress.com/book/view/1430219890 >>> Follow me: http://twitter.com/dpp >>> Surf the harmonics >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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. >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Surf the harmonics >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@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. >> > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Support for page and snippet level localization
mm im not sure who would take this on, as I think i've been doing most of the localisation stuff and I don't have capacity to do anything about this for quite some time unless it becomes an urgent priority. Any discussion must take place on this list, not on (or in) tickets, review board or otherwise. Right now, I think you could service the need yourself using locale calculator and resourceBundleFactories. To that end, the work we are talking about here is "helpers" rather than core functionality. Not to belittle it, as it could be quite useful - its just a case of working out what needs doing and where. Create a ticket in Assembla, mark it as webkit enhancement and assign it to me. I'll look at it, some when. Cheers, Tim On 9 Feb 2010, at 22:25, Hugo Palma wrote: > I understand, just trying to share some of my own experience and ideas. > So, should i create an issue for further discussion or do we just let it be ? > > On Tue, Feb 9, 2010 at 18:43, Timothy Perrett wrote: > Appreciate where you are coming from, however, the defaults are working quite > well so perhaps it would be frugal to break some other boxed configurations > into lift-localization or something... Such as page related resource bundles. > > Needs some thinking, but its certainly possible. Lift is extremely flexible > in this regard. > > Cheers, Tim > > On 9 Feb 2010, at 17:52, Hugo Palma wrote: > >> So what you're saying is that a page can include a bunch of snippets and >> that's why it doesn't be an advantage to have page resource bundles ? >> >> I'm sorry but i don't see why. >> I'm not sure how people are using resource bundles with Lift now but the way >> i would do it would be to create a resource bundle for each page that would >> have the properties that are specific to that page and then i would have one >> or more bundles with properties that would be used in several pages across >> the application. >> >> I think this makes sense in large applications because it's just a natural >> way of organizing your translated text. >> I realize this is possible with Lift now, but it has the following problems: >> >> - Even if you separate in bundles the properties are globally available. >> There's no bundle "namespace" concept. For example, i might want to have the >> property page-name with the current page name. And if i'm on the home page i >> want it to translate to "Home" and if i'm on the search page i want it to >> translate to "Search". This could be possible with this. >> >> - I have to register every single resource bundle in >> LiftRules.resourceNames. Although not critical this could easily be replace >> with automatic bindle discovery like i suggested. >> >> On Tue, Feb 9, 2010 at 17:38, Timothy Perrett >> wrote: >> The analogy would be MVC controllers... the index method has an index >> page and an index resource bundle. Within Lift, we dont use >> controllers, so there is nothing stopping you calling a whole bunch of >> snippets on a single page - thus, there would be no single "page" >> resource bundle (that is, it wouldn't buy you anything IMHO) as >> different snippets might share localised text or whatever. I guess im >> just trying to say things are not silo'ed in Lift. >> >> Does that add some more clarity to my statement? >> >> Cheers, Tim >> >> On Feb 9, 2:47 pm, Hugo Palma wrote: >> > Sorry Tim but i don't quite understand what you mean by "page is >> > scoped to a single snippet" and that invalidates that you have a >> > resource bundle per page. Sorry is this is clear to everyone else but >> > i'm new with Lift so i'm still grasping basic concepts. >> > >> > On Feb 8, 10:49 pm, Timothy Perrett wrote: >> > >> > >> > >> > > That wouldn't work for Lift as it assumes a page is scoped to a single >> > > snippet. It works with Tapestry because its an MVC framework. >> > >> > > Lift is *not* MVC. >> > >> > > Have you seen LiftRules.resourceBundleFactories ? >> > >> > > Cheers, Tim >> > >> > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: >> > >> > > > Lift only support global resource bundles, i think it would be very >> > > > useful if page and snipped level resource bundles were supported. >> > > > For example, if i have a page "index" it would automatically have >> > > > access to the index.properties_ bundle. Obviously this bundle >> > > > would not be accessible from any other page. >> > >> > > > I come from an Apache Tapestry background that has page and component >> > > > level localization and it proved very useful. >> > >> > > > What do you guys think about this ? >> > >> > > > -- >> >> > > > You received this message because you are subscribed to the Google >> > > > Groups "Lift" group. >> > > > To post to this group, send email to lift...@googlegroups.com. >> > > > To unsubscribe from this group, send email to >> > > > liftweb+unsubscr...@googlegroups.com. >> > > > For more options, visit this group >> > > > athttp://groups.google.com/group/liftweb?hl=en. >>
Re: [Lift] Mapped(Date)(Time) formatter/parser
Naftoli Gugenheim writes: > It would be really great if you could take a look at TimeHelpers and my diff > (vs. original), on RB and wip-nafg-date. I'll be glad to take a look, but not really sure what it is you want me to look at :-) > I asked about your time zone only because I was wondering if you'd be around > when I pushed it, but it's pushed. Ok, it's getting late here but I'll look tomorrow... /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Why not SHtml?
On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim wrote: > Could you give me exact instructions what to do to test my code on 2.8? git checkout -b 280_port_refresh origin/280_port_refresh cd framework/lift-persistence/lift-mapper emacs $(grep -l "FIXME: 280" $(find . -name *.scala)) remove the comments around your code. Make it compile and pass the existing tests. > Thanks. > > 2010/2/7 David Pollak > >> >> >> On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim >> wrote: >> >>> So if I get around to it would it indeed be preferable to point it to >>> SHtml? >>> >> >> Changing the code is one of the lowest priorities I could imagine. I >> would say that closing the stuff you've had on review board for > 1 months >> would be much higher priority. Adding copyright notices and other headers >> to the code you've written in Lift is a higher priority. Helping to port >> your code to 2.8 would be a higher priority. >> >> >>> >>> - >>> David Pollak wrote: >>> >>> On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim >> >wrote: >>> >>> > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly >>> > rather than using SHtml? Is it not duplicate code? >>> > >>> >>> Because the Mapper code was the earliest Lift code... written long before >>> SHtml. >>> >>> >>> > Thanks. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Lift" group. >>> > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >>> Beginning Scala http://www.apress.com/book/view/1430219890 >>> Follow me: http://twitter.com/dpp >>> Surf the harmonics >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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. >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Surf the harmonics >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@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. >> > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Why not SHtml?
Could you give me exact instructions what to do to test my code on 2.8? Thanks. 2010/2/7 David Pollak > > > On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim wrote: > >> So if I get around to it would it indeed be preferable to point it to >> SHtml? >> > > Changing the code is one of the lowest priorities I could imagine. I would > say that closing the stuff you've had on review board for > 1 months would > be much higher priority. Adding copyright notices and other headers to the > code you've written in Lift is a higher priority. Helping to port your code > to 2.8 would be a higher priority. > > >> >> - >> David Pollak wrote: >> >> On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim > >wrote: >> >> > Hello. Why do Mapper's toForm implementations use S.fmapFunc directly >> > rather than using SHtml? Is it not duplicate code? >> > >> >> Because the Mapper code was the earliest Lift code... written long before >> SHtml. >> >> >> > Thanks. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Lift" group. >> > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Surf the harmonics >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@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. >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Support for page and snippet level localization
I understand, just trying to share some of my own experience and ideas. So, should i create an issue for further discussion or do we just let it be ? On Tue, Feb 9, 2010 at 18:43, Timothy Perrett wrote: > Appreciate where you are coming from, however, the defaults are working > quite well so perhaps it would be frugal to break some other boxed > configurations into lift-localization or something... Such as page related > resource bundles. > > Needs some thinking, but its certainly possible. Lift is extremely flexible > in this regard. > > Cheers, Tim > > On 9 Feb 2010, at 17:52, Hugo Palma wrote: > > So what you're saying is that a page can include a bunch of snippets and > that's why it doesn't be an advantage to have page resource bundles ? > > I'm sorry but i don't see why. > I'm not sure how people are using resource bundles with Lift now but the > way i would do it would be to create a resource bundle for each page that > would have the properties that are specific to that page and then i would > have one or more bundles with properties that would be used in several > pages across the application. > > I think this makes sense in large applications because it's just a natural > way of organizing your translated text. > I realize this is possible with Lift now, but it has the following > problems: > > - Even if you separate in bundles the properties are globally available. > There's no bundle "namespace" concept. For example, i might want to have the > property page-name with the current page name. And if i'm on the home page i > want it to translate to "Home" and if i'm on the search page i want it to > translate to "Search". This could be possible with this. > > - I have to register every single resource bundle in > LiftRules.resourceNames. Although not critical this could easily be replace > with automatic bindle discovery like i suggested. > > On Tue, Feb 9, 2010 at 17:38, Timothy Perrett wrote: > >> The analogy would be MVC controllers... the index method has an index >> page and an index resource bundle. Within Lift, we dont use >> controllers, so there is nothing stopping you calling a whole bunch of >> snippets on a single page - thus, there would be no single "page" >> resource bundle (that is, it wouldn't buy you anything IMHO) as >> different snippets might share localised text or whatever. I guess im >> just trying to say things are not silo'ed in Lift. >> >> Does that add some more clarity to my statement? >> >> Cheers, Tim >> >> On Feb 9, 2:47 pm, Hugo Palma wrote: >> > Sorry Tim but i don't quite understand what you mean by "page is >> > scoped to a single snippet" and that invalidates that you have a >> > resource bundle per page. Sorry is this is clear to everyone else but >> > i'm new with Lift so i'm still grasping basic concepts. >> > >> > On Feb 8, 10:49 pm, Timothy Perrett wrote: >> > >> > >> > >> > > That wouldn't work for Lift as it assumes a page is scoped to a single >> snippet. It works with Tapestry because its an MVC framework. >> > >> > > Lift is *not* MVC. >> > >> > > Have you seen LiftRules.resourceBundleFactories ? >> > >> > > Cheers, Tim >> > >> > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: >> > >> > > > Lift only support global resource bundles, i think it would be very >> > > > useful if page and snipped level resource bundles were supported. >> > > > For example, if i have a page "index" it would automatically have >> > > > access to the index.properties_ bundle. Obviously this >> bundle >> > > > would not be accessible from any other page. >> > >> > > > I come from an Apache Tapestry background that has page and >> component >> > > > level localization and it proved very useful. >> > >> > > > What do you guys think about this ? >> > >> > > > -- >> >> > > > You received this message because you are subscribed to the Google >> Groups "Lift" group. >> > > > To post to this group, send email to lift...@googlegroups.com. >> > > > To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com >> . >> > > > For more options, visit this group athttp:// >> groups.google.com/group/liftweb?hl=en. >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@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. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com.
[Lift] Logging error when building lift
Does this mean I'm not up to date? Or were the tests not updated with the change to logging? When building Lift I get --- T E S T S --- Running net.liftweb.webapptest.ToHeadUsagesTest SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/C:/Users/Naftoli/.m2/repository/org/slf4j/slf4j-simple/1.5.10/slf4j-simple-1.5.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/Users/Naftoli/.m2/repository/org/slf4j/slf4j-log4j12/1.5.0/slf4j-log4j12-1.5.0.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. 0 [main] INFO org.mortbay.log - Logging to org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog 94 [main] INFO org.mortbay.log - jetty-6.1.22 468 [main] INFO org.mortbay.log - NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet 151189 [main] INFO org.mortbay.log - Started socketconnec...@0.0.0.0:8989 log4j:WARN No appenders could be found for logger (com.gargoylesoftware.htmlunit.WebClient). log4j:WARN Please initialize the log4j system properly. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Helpers.bind question
On Tue, Feb 9, 2010 at 12:04 PM, GA wrote:
> What we have here is a iphone native application that has the help screens
> in HTML. The help screens are in multiple languages and are stored in the
> database.
>
> When the application starts, it checks in the server for updates in the
> help pages calling a particular URL but with different context parameters.
> The downloaded HTML is stored locally in the app to be able to work when the
> phone is offline. The downloaded content has a common template for each
> language and it loads the content from the database.
>
> The help content has been written as HTML in MS Word. It has been already
> formatted there. That is why it is stored altogether in the database. It is
> not a typical lift web site.
>
> If it is not possible to pass the characters unescaped, then we will have
> to create the pages individually loading just the text from the database. It
> is not a big deal and I know it would be cleaner, but I wanted to know if we
> can avoid this change.
>
As Naftoli mentioned, scala.xml.Unparsed(string) will pass string to the
output. If the string is not valid XML, the client browser may complain.
>
> Thanks in advance,
>
> GA
>
> On Feb 9, 2010, at 8:31 PM, David Pollak wrote:
>
>
>
> On Tue, Feb 9, 2010 at 10:00 AM, GA wrote:
>
>> Hello guys,
>>
>> I have a very silly question. I have a snippet that reads a string field
>> from the database and it inserts it within a html page.
>>
>> So far so good. The text that the snippet reads from the database is a
>> piece of html code. The problem is that the bind method replaces the "<" and
>> ">" within the string with "<" and ">". The snippet looks like
>> that:
>>
>> if (context != "") {
>> ContextHelp.findByKey(context.toLong) match {
>> case Full(help) => {
>> val message = help.contextHelp
>> Helpers.bind("b", in, "text" -> message.toString)
>> }
>> case _ => Helpers.bind("b", in, "text" -> "Context not
>> found")
>> }
>> } else Helpers.bind("b", in, "text" -> "The URL is invalid. ")
>>
>>
>> The HTML that calls the snippet looks like this:
>>
>>
>>
>>
>>
>> What should I do to get the html content without changes in the tags?
>>
>
> It is not Helpers.bind() that's transforming the text. It's the XML
> libraries that properly XML escape Text() elements when they are converted
> from XML representation to a byte stream.
>
> In almost every context, this is what you want... you want Strings to be
> properly escaped. If that was not the case, there would be tons of cross
> site scripting issues.
>
> So, what is the type of "message" in the code above? Do you really,
> really, really mean for the String representation of message to be not XML
> escaped?
>
>
>>
>> Thanks in advance,
>>
>> GA
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
Re: [Lift] Helpers.bind question
You have two options: scala.xml.Unparsed(theString), and parsing it explicitly
into a NodeSeq (see scala.xml.XML or Lift's equivalent which I haven't used but
believe exists).
-
GA wrote:
What we have here is a iphone native application that has the help screens in
HTML. The help screens are in multiple languages and are stored in the database.
When the application starts, it checks in the server for updates in the help
pages calling a particular URL but with different context parameters. The
downloaded HTML is stored locally in the app to be able to work when the phone
is offline. The downloaded content has a common template for each language and
it loads the content from the database.
The help content has been written as HTML in MS Word. It has been already
formatted there. That is why it is stored altogether in the database. It is not
a typical lift web site.
If it is not possible to pass the characters unescaped, then we will have to
create the pages individually loading just the text from the database. It is
not a big deal and I know it would be cleaner, but I wanted to know if we can
avoid this change.
Thanks in advance,
GA
On Feb 9, 2010, at 8:31 PM, David Pollak wrote:
>
>
> On Tue, Feb 9, 2010 at 10:00 AM, GA wrote:
> Hello guys,
>
> I have a very silly question. I have a snippet that reads a string field from
> the database and it inserts it within a html page.
>
> So far so good. The text that the snippet reads from the database is a piece
> of html code. The problem is that the bind method replaces the "<" and ">"
> within the string with "<" and ">". The snippet looks like that:
>
> if (context != "") {
> ContextHelp.findByKey(context.toLong) match {
> case Full(help) => {
> val message = help.contextHelp
> Helpers.bind("b", in, "text" -> message.toString)
> }
> case _ => Helpers.bind("b", in, "text" -> "Context not found")
> }
> } else Helpers.bind("b", in, "text" -> "The URL is invalid. ")
>
>
> The HTML that calls the snippet looks like this:
>
>
>
>
>
> What should I do to get the html content without changes in the tags?
>
> It is not Helpers.bind() that's transforming the text. It's the XML
> libraries that properly XML escape Text() elements when they are converted
> from XML representation to a byte stream.
>
> In almost every context, this is what you want... you want Strings to be
> properly escaped. If that was not the case, there would be tons of cross
> site scripting issues.
>
> So, what is the type of "message" in the code above? Do you really, really,
> really mean for the String representation of message to be not XML escaped?
>
>
> Thanks in advance,
>
> GA
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
Re: [Lift] Mapped(Date)(Time) formatter/parser
It would be really great if you could take a look at TimeHelpers and my diff (vs. original), on RB and wip-nafg-date. I asked about your time zone only because I was wondering if you'd be around when I pushed it, but it's pushed. - Jeppe Nejsum Madsen wrote: Naftoli Gugenheim writes: > Wait--are you saying TimeHelpers should use ConversionRules and > ConversionRules should *not* reference TimeHelpers? I think so (without knowing too much about the code :-) > If so it would involve a lot of refactoring, In that case, suggest we postpone that bit :-) > although I think I hear where you're coming from. I'll try to push > the wip-nafg-date branch a bit later. What time zone are you in? CET /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Helpers.bind question
What we have here is a iphone native application that has the help screens in
HTML. The help screens are in multiple languages and are stored in the database.
When the application starts, it checks in the server for updates in the help
pages calling a particular URL but with different context parameters. The
downloaded HTML is stored locally in the app to be able to work when the phone
is offline. The downloaded content has a common template for each language and
it loads the content from the database.
The help content has been written as HTML in MS Word. It has been already
formatted there. That is why it is stored altogether in the database. It is not
a typical lift web site.
If it is not possible to pass the characters unescaped, then we will have to
create the pages individually loading just the text from the database. It is
not a big deal and I know it would be cleaner, but I wanted to know if we can
avoid this change.
Thanks in advance,
GA
On Feb 9, 2010, at 8:31 PM, David Pollak wrote:
>
>
> On Tue, Feb 9, 2010 at 10:00 AM, GA wrote:
> Hello guys,
>
> I have a very silly question. I have a snippet that reads a string field from
> the database and it inserts it within a html page.
>
> So far so good. The text that the snippet reads from the database is a piece
> of html code. The problem is that the bind method replaces the "<" and ">"
> within the string with "<" and ">". The snippet looks like that:
>
> if (context != "") {
> ContextHelp.findByKey(context.toLong) match {
> case Full(help) => {
> val message = help.contextHelp
> Helpers.bind("b", in, "text" -> message.toString)
> }
> case _ => Helpers.bind("b", in, "text" -> "Context not found")
> }
> } else Helpers.bind("b", in, "text" -> "The URL is invalid. ")
>
>
> The HTML that calls the snippet looks like this:
>
>
>
>
>
> What should I do to get the html content without changes in the tags?
>
> It is not Helpers.bind() that's transforming the text. It's the XML
> libraries that properly XML escape Text() elements when they are converted
> from XML representation to a byte stream.
>
> In almost every context, this is what you want... you want Strings to be
> properly escaped. If that was not the case, there would be tons of cross
> site scripting issues.
>
> So, what is the type of "message" in the code above? Do you really, really,
> really mean for the String representation of message to be not XML escaped?
>
>
> Thanks in advance,
>
> GA
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
Re: [Lift] Helpers.bind question
On Tue, Feb 9, 2010 at 10:00 AM, GA wrote:
> Hello guys,
>
> I have a very silly question. I have a snippet that reads a string field
> from the database and it inserts it within a html page.
>
> So far so good. The text that the snippet reads from the database is a
> piece of html code. The problem is that the bind method replaces the "<" and
> ">" within the string with "<" and ">". The snippet looks like that:
>
> if (context != "") {
> ContextHelp.findByKey(context.toLong) match {
> case Full(help) => {
> val message = help.contextHelp
> Helpers.bind("b", in, "text" -> message.toString)
> }
> case _ => Helpers.bind("b", in, "text" -> "Context not
> found")
> }
> } else Helpers.bind("b", in, "text" -> "The URL is invalid. ")
>
>
> The HTML that calls the snippet looks like this:
>
>
>
>
>
> What should I do to get the html content without changes in the tags?
>
It is not Helpers.bind() that's transforming the text. It's the XML
libraries that properly XML escape Text() elements when they are converted
from XML representation to a byte stream.
In almost every context, this is what you want... you want Strings to be
properly escaped. If that was not the case, there would be tons of cross
site scripting issues.
So, what is the type of "message" in the code above? Do you really, really,
really mean for the String representation of message to be not XML escaped?
>
> Thanks in advance,
>
> GA
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
Re: [Lift] Mapped(Date)(Time) formatter/parser
Naftoli Gugenheim writes: > Wait--are you saying TimeHelpers should use ConversionRules and > ConversionRules should *not* reference TimeHelpers? I think so (without knowing too much about the code :-) > If so it would involve a lot of refactoring, In that case, suggest we postpone that bit :-) > although I think I hear where you're coming from. I'll try to push > the wip-nafg-date branch a bit later. What time zone are you in? CET /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Welcome javier Goday to the Lift committers
David Pollak writes: > Folks, > > Please join me in welcoming Javier Goday to the Lift committers. Javier > wrote the Lift LDAP module and now that he's a committer, he can make the > LDAP module part of the official Lift distribution (and the crowd goes > wild). > > Welcome Javier!! Cool! Welcome :-) /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] CRUDify Customized Access Control Issues
Robert Thurnher writes: > On 9 February 2010 16:04, Jeppe Nejsum Madsen wrote: [...] I suggest you upgrade to 2.0-SNAPSHOT (or M1}, much improved :-) >>> >>> Am definitely going to give that a spin (wanted to get a better feel >>> of Lift in general before it). >>> BTW, how "safe" is it to use M* resp. SNAPSHOT releases? >> >> The milestones are fairly safe. I can only recall one that didn't work >> as expected. Snapshots are mostly fine, with an occasional breakage. >> >> We're running SNAPSHOT on our production site and I can only recall a >> few situations where deployment failed, and none where functionality >> was compromised > > Thanks for info, good to know. > Going to upgrade to 2.0-M1 (or at least the latest 1.1 one) ASAP. Don't use the 1.1 ones, there was a naming change 1.1 -> 2.0, so 2.0-M1 is considered the best non 1.0.x release...(I'll even say the best release :-) /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Support for page and snippet level localization
Appreciate where you are coming from, however, the defaults are working quite well so perhaps it would be frugal to break some other boxed configurations into lift-localization or something... Such as page related resource bundles. Needs some thinking, but its certainly possible. Lift is extremely flexible in this regard. Cheers, Tim On 9 Feb 2010, at 17:52, Hugo Palma wrote: > So what you're saying is that a page can include a bunch of snippets and > that's why it doesn't be an advantage to have page resource bundles ? > > I'm sorry but i don't see why. > I'm not sure how people are using resource bundles with Lift now but the way > i would do it would be to create a resource bundle for each page that would > have the properties that are specific to that page and then i would have one > or more bundles with properties that would be used in several pages across > the application. > > I think this makes sense in large applications because it's just a natural > way of organizing your translated text. > I realize this is possible with Lift now, but it has the following problems: > > - Even if you separate in bundles the properties are globally available. > There's no bundle "namespace" concept. For example, i might want to have the > property page-name with the current page name. And if i'm on the home page i > want it to translate to "Home" and if i'm on the search page i want it to > translate to "Search". This could be possible with this. > > - I have to register every single resource bundle in LiftRules.resourceNames. > Although not critical this could easily be replace with automatic bindle > discovery like i suggested. > > On Tue, Feb 9, 2010 at 17:38, Timothy Perrett wrote: > The analogy would be MVC controllers... the index method has an index > page and an index resource bundle. Within Lift, we dont use > controllers, so there is nothing stopping you calling a whole bunch of > snippets on a single page - thus, there would be no single "page" > resource bundle (that is, it wouldn't buy you anything IMHO) as > different snippets might share localised text or whatever. I guess im > just trying to say things are not silo'ed in Lift. > > Does that add some more clarity to my statement? > > Cheers, Tim > > On Feb 9, 2:47 pm, Hugo Palma wrote: > > Sorry Tim but i don't quite understand what you mean by "page is > > scoped to a single snippet" and that invalidates that you have a > > resource bundle per page. Sorry is this is clear to everyone else but > > i'm new with Lift so i'm still grasping basic concepts. > > > > On Feb 8, 10:49 pm, Timothy Perrett wrote: > > > > > > > > > That wouldn't work for Lift as it assumes a page is scoped to a single > > > snippet. It works with Tapestry because its an MVC framework. > > > > > Lift is *not* MVC. > > > > > Have you seen LiftRules.resourceBundleFactories ? > > > > > Cheers, Tim > > > > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: > > > > > > Lift only support global resource bundles, i think it would be very > > > > useful if page and snipped level resource bundles were supported. > > > > For example, if i have a page "index" it would automatically have > > > > access to the index.properties_ bundle. Obviously this bundle > > > > would not be accessible from any other page. > > > > > > I come from an Apache Tapestry background that has page and component > > > > level localization and it proved very useful. > > > > > > What do you guys think about this ? > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Lift" group. > > > > To post to this group, send email to lift...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > liftweb+unsubscr...@googlegroups.com. > > > > For more options, visit this group > > > > athttp://groups.google.com/group/liftweb?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. > > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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] Helpers.bind question
Hello guys,
I have a very silly question. I have a snippet that reads a string field from
the database and it inserts it within a html page.
So far so good. The text that the snippet reads from the database is a piece of
html code. The problem is that the bind method replaces the "<" and ">" within
the string with "<" and ">". The snippet looks like that:
if (context != "") {
ContextHelp.findByKey(context.toLong) match {
case Full(help) => {
val message = help.contextHelp
Helpers.bind("b", in, "text" -> message.toString)
}
case _ => Helpers.bind("b", in, "text" -> "Context not found")
}
} else Helpers.bind("b", in, "text" -> "The URL is invalid. ")
The HTML that calls the snippet looks like this:
What should I do to get the html content without changes in the tags?
Thanks in advance,
GA
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
Re: [Lift] Re: Support for page and snippet level localization
So what you're saying is that a page can include a bunch of snippets and that's why it doesn't be an advantage to have page resource bundles ? I'm sorry but i don't see why. I'm not sure how people are using resource bundles with Lift now but the way i would do it would be to create a resource bundle for each page that would have the properties that are specific to that page and then i would have one or more bundles with properties that would be used in several pages across the application. I think this makes sense in large applications because it's just a natural way of organizing your translated text. I realize this is possible with Lift now, but it has the following problems: - Even if you separate in bundles the properties are globally available. There's no bundle "namespace" concept. For example, i might want to have the property page-name with the current page name. And if i'm on the home page i want it to translate to "Home" and if i'm on the search page i want it to translate to "Search". This could be possible with this. - I have to register every single resource bundle in LiftRules.resourceNames. Although not critical this could easily be replace with automatic bindle discovery like i suggested. On Tue, Feb 9, 2010 at 17:38, Timothy Perrett wrote: > The analogy would be MVC controllers... the index method has an index > page and an index resource bundle. Within Lift, we dont use > controllers, so there is nothing stopping you calling a whole bunch of > snippets on a single page - thus, there would be no single "page" > resource bundle (that is, it wouldn't buy you anything IMHO) as > different snippets might share localised text or whatever. I guess im > just trying to say things are not silo'ed in Lift. > > Does that add some more clarity to my statement? > > Cheers, Tim > > On Feb 9, 2:47 pm, Hugo Palma wrote: > > Sorry Tim but i don't quite understand what you mean by "page is > > scoped to a single snippet" and that invalidates that you have a > > resource bundle per page. Sorry is this is clear to everyone else but > > i'm new with Lift so i'm still grasping basic concepts. > > > > On Feb 8, 10:49 pm, Timothy Perrett wrote: > > > > > > > > > That wouldn't work for Lift as it assumes a page is scoped to a single > snippet. It works with Tapestry because its an MVC framework. > > > > > Lift is *not* MVC. > > > > > Have you seen LiftRules.resourceBundleFactories ? > > > > > Cheers, Tim > > > > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: > > > > > > Lift only support global resource bundles, i think it would be very > > > > useful if page and snipped level resource bundles were supported. > > > > For example, if i have a page "index" it would automatically have > > > > access to the index.properties_ bundle. Obviously this bundle > > > > would not be accessible from any other page. > > > > > > I come from an Apache Tapestry background that has page and component > > > > level localization and it proved very useful. > > > > > > What do you guys think about this ? > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups "Lift" group. > > > > To post to this group, send email to lift...@googlegroups.com. > > > > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > > > > For more options, visit this group athttp:// > groups.google.com/group/liftweb?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Support for page and snippet level localization
Come to think of it - if you really wanted to have a resource bundle for each page... you could do that using the resource bundle factories I listed earlier. Cheers, Tim On Feb 9, 5:38 pm, Timothy Perrett wrote: > The analogy would be MVC controllers... the index method has an index > page and an index resource bundle. Within Lift, we dont use > controllers, so there is nothing stopping you calling a whole bunch of > snippets on a single page - thus, there would be no single "page" > resource bundle (that is, it wouldn't buy you anything IMHO) as > different snippets might share localised text or whatever. I guess im > just trying to say things are not silo'ed in Lift. > > Does that add some more clarity to my statement? > > Cheers, Tim > > On Feb 9, 2:47 pm, Hugo Palma wrote: > > > > > Sorry Tim but i don't quite understand what you mean by "page is > > scoped to a single snippet" and that invalidates that you have a > > resource bundle per page. Sorry is this is clear to everyone else but > > i'm new with Lift so i'm still grasping basic concepts. > > > On Feb 8, 10:49 pm, Timothy Perrett wrote: > > > > That wouldn't work for Lift as it assumes a page is scoped to a single > > > snippet. It works with Tapestry because its an MVC framework. > > > > Lift is *not* MVC. > > > > Have you seen LiftRules.resourceBundleFactories ? > > > > Cheers, Tim > > > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: > > > > > Lift only support global resource bundles, i think it would be very > > > > useful if page and snipped level resource bundles were supported. > > > > For example, if i have a page "index" it would automatically have > > > > access to the index.properties_ bundle. Obviously this bundle > > > > would not be accessible from any other page. > > > > > I come from an Apache Tapestry background that has page and component > > > > level localization and it proved very useful. > > > > > What do you guys think about this ? > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Lift" group. > > > > To post to this group, send email to lift...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > liftweb+unsubscr...@googlegroups.com. > > > > For more options, visit this group > > > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Support for page and snippet level localization
The analogy would be MVC controllers... the index method has an index page and an index resource bundle. Within Lift, we dont use controllers, so there is nothing stopping you calling a whole bunch of snippets on a single page - thus, there would be no single "page" resource bundle (that is, it wouldn't buy you anything IMHO) as different snippets might share localised text or whatever. I guess im just trying to say things are not silo'ed in Lift. Does that add some more clarity to my statement? Cheers, Tim On Feb 9, 2:47 pm, Hugo Palma wrote: > Sorry Tim but i don't quite understand what you mean by "page is > scoped to a single snippet" and that invalidates that you have a > resource bundle per page. Sorry is this is clear to everyone else but > i'm new with Lift so i'm still grasping basic concepts. > > On Feb 8, 10:49 pm, Timothy Perrett wrote: > > > > > That wouldn't work for Lift as it assumes a page is scoped to a single > > snippet. It works with Tapestry because its an MVC framework. > > > Lift is *not* MVC. > > > Have you seen LiftRules.resourceBundleFactories ? > > > Cheers, Tim > > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: > > > > Lift only support global resource bundles, i think it would be very > > > useful if page and snipped level resource bundles were supported. > > > For example, if i have a page "index" it would automatically have > > > access to the index.properties_ bundle. Obviously this bundle > > > would not be accessible from any other page. > > > > I come from an Apache Tapestry background that has page and component > > > level localization and it proved very useful. > > > > What do you guys think about this ? > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Lift" group. > > > To post to this group, send email to lift...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > liftweb+unsubscr...@googlegroups.com. > > > For more options, visit this group > > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Support for page and snippet level localization
Some of the code needs adjusting because of an API change since I wrote this, but this should give you a good overview of lifts localization and templating: http://is.gd/81uAi Cheers, Tim On Feb 9, 5:29 pm, James Matlik wrote: > I would also be very interested in more detail on this topic. I've been > toying with designs with a variety of technologies (a self-driven academic > activity this far) to formulate how a massively multilingual site (upwards > of 12 languages) could be implemented. I've not had much luck understanding > the capabilities and limitations (perhaps a better word is boundaries) of > lift's templating system for both language support and performance/resource > usage for huge quantities of content. > > A bit off topic but related... There has been talk before on the mailing > list about creating a CMS. Has anything come of that? > > Regards, > James > > On Feb 9, 2010 9:47 AM, "Hugo Palma" wrote: > > Sorry Tim but i don't quite understand what you mean by "page is > scoped to a single snippet" and that invalidates that you have a > resource bundle per page. Sorry is this is clear to everyone else but > i'm new with Lift so i'm still grasping basic concepts. > > On Feb 8, 10:49 pm, Timothy Perrett wrote:> That > wouldn't work for Lift ... > > > For more options, visit this group athttp:// > > groups.google.com/group/liftweb?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post... -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Support for page and snippet level localization
I would also be very interested in more detail on this topic. I've been toying with designs with a variety of technologies (a self-driven academic activity this far) to formulate how a massively multilingual site (upwards of 12 languages) could be implemented. I've not had much luck understanding the capabilities and limitations (perhaps a better word is boundaries) of lift's templating system for both language support and performance/resource usage for huge quantities of content. A bit off topic but related... There has been talk before on the mailing list about creating a CMS. Has anything come of that? Regards, James On Feb 9, 2010 9:47 AM, "Hugo Palma" wrote: Sorry Tim but i don't quite understand what you mean by "page is scoped to a single snippet" and that invalidates that you have a resource bundle per page. Sorry is this is clear to everyone else but i'm new with Lift so i'm still grasping basic concepts. On Feb 8, 10:49 pm, Timothy Perrett wrote: > That wouldn't work for Lift ... > > For more options, visit this group athttp:// groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post... -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Snippet with no reflection an no massive case statement
I care because in the wiki it says this about reflection snippets: "works perfectly for development / low volume deployment" which isn't the case for the application i'm building. On 9 Fev, 17:14, David Pollak wrote: > On Tue, Feb 9, 2010 at 9:10 AM, Hugo Palma wrote: > > Why doesn't Lift create the mapping at startup using reflection ? > > It's not using reflection that's the problem, it's using reflection at > > runtime for every single snippet usage. > > Why do you care? The cost of doing a method dispatch via reflection is > about 5x the cost of a doing a method call on an interface with is about 2x > more costly than doing a method call on a class. The amount of time to do > reflection on the 10 or 20 snippets you may have on a page is unmeasurably > small compared to the cost of rendering the page. > > > > > I may be over simplifying things, but if at startup Lift would go > > through all snippet classes and using reflection found all the methods > > kept all the mappings somewhere in memory i think it could work. > > Is this doable ? > > No, it is not possible at start-up time to determine all the classes that > might be snippets. > > > > > > > > > On 9 Fev, 17:01, Timothy Perrett wrote: > > > So you don't want to write any explicit mapping, and you don't want to > > use reflection??? How would you propose Lift know what your asking for? > > > > Im afraid voodoo is not yet compatible with the JVM ;-) > > > > Cheers, Tim > > > > On 9 Feb 2010, at 16:54, Hugo Palma wrote: > > > > > I just readhttp://wiki.github.com/dpp/liftweb/about-snippetsandi > > > > have the following question: > > > > > So is really the only way to avoid having a reflection call every time > > > > you use a snippet to use a DispatchSnippet with a case statement for > > > > every method ? > > > > It's just that i don't really think that the case is a very clean way > > > > of doing things. Can be ok for a couple of methods but it can be > > > > really ugly with more than that. > > > > > So, is there any other way ? > > > > Thanks. > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups "Lift" group. > > > > To post to this group, send email to lift...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com > > > > . > > > > For more options, visit this group athttp:// > > groups.google.com/group/liftweb?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@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, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Snippet with no reflection an no massive case statement
I just started using Lift so i'm trying to understand the "Lift way" of doing things. I offer suggestions whenever i think it's a valid one and i'm not just saying something that doesn't bring any value to the discussion. Hopefully that will happen more in the future as i learn more about the framework. Thanks for you help. On 9 Fev, 17:07, David Pollak wrote: > Rather than complain about things, it would be helpful if you offered > suggestions or alternatives. You complained about Lift's use of Maven to > bootstrap without offering alternatives. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Snippet with no reflection an no massive case statement
On Tue, Feb 9, 2010 at 9:10 AM, Hugo Palma wrote: > Why doesn't Lift create the mapping at startup using reflection ? > It's not using reflection that's the problem, it's using reflection at > runtime for every single snippet usage. > Why do you care? The cost of doing a method dispatch via reflection is about 5x the cost of a doing a method call on an interface with is about 2x more costly than doing a method call on a class. The amount of time to do reflection on the 10 or 20 snippets you may have on a page is unmeasurably small compared to the cost of rendering the page. > > I may be over simplifying things, but if at startup Lift would go > through all snippet classes and using reflection found all the methods > kept all the mappings somewhere in memory i think it could work. > Is this doable ? > No, it is not possible at start-up time to determine all the classes that might be snippets. > > On 9 Fev, 17:01, Timothy Perrett wrote: > > So you don't want to write any explicit mapping, and you don't want to > use reflection??? How would you propose Lift know what your asking for? > > > > Im afraid voodoo is not yet compatible with the JVM ;-) > > > > Cheers, Tim > > > > On 9 Feb 2010, at 16:54, Hugo Palma wrote: > > > > > > > > > I just readhttp://wiki.github.com/dpp/liftweb/about-snippetsand i > > > have the following question: > > > > > So is really the only way to avoid having a reflection call every time > > > you use a snippet to use a DispatchSnippet with a case statement for > > > every method ? > > > It's just that i don't really think that the case is a very clean way > > > of doing things. Can be ok for a couple of methods but it can be > > > really ugly with more than that. > > > > > So, is there any other way ? > > > Thanks. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Lift" group. > > > To post to this group, send email to lift...@googlegroups.com. > > > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > > > For more options, visit this group athttp:// > groups.google.com/group/liftweb?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Snippet with no reflection an no massive case statement
Why doesn't Lift create the mapping at startup using reflection ? It's not using reflection that's the problem, it's using reflection at runtime for every single snippet usage. I may be over simplifying things, but if at startup Lift would go through all snippet classes and using reflection found all the methods kept all the mappings somewhere in memory i think it could work. Is this doable ? On 9 Fev, 17:01, Timothy Perrett wrote: > So you don't want to write any explicit mapping, and you don't want to use > reflection??? How would you propose Lift know what your asking for? > > Im afraid voodoo is not yet compatible with the JVM ;-) > > Cheers, Tim > > On 9 Feb 2010, at 16:54, Hugo Palma wrote: > > > > > I just readhttp://wiki.github.com/dpp/liftweb/about-snippetsand i > > have the following question: > > > So is really the only way to avoid having a reflection call every time > > you use a snippet to use a DispatchSnippet with a case statement for > > every method ? > > It's just that i don't really think that the case is a very clean way > > of doing things. Can be ok for a couple of methods but it can be > > really ugly with more than that. > > > So, is there any other way ? > > Thanks. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Snippet with no reflection an no massive case statement
Rather than complain about things, it would be helpful if you offered
suggestions or alternatives. You complained about Lift's use of Maven to
bootstrap without offering alternatives.
On Tue, Feb 9, 2010 at 8:54 AM, Hugo Palma wrote:
> I just read http://wiki.github.com/dpp/liftweb/about-snippets and i
> have the following question:
>
> So is really the only way to avoid having a reflection call every time
> you use a snippet
What is your objection to using reflection?
> to use a DispatchSnippet with a case statement for
> every method ?
>
Keep in mind that a Map() in Scala is a partial function, so you can do the
following:
class MySnippets extends DispatchSnippet {
def dispatch = Map("hello" -> hello _, "bye" -> bye _)
def hello(in: NodeSeq): NodeSeq = ...
def bye(in: NodeSeq): NodeSeq = ...
}
> It's just that i don't really think that the case is a very clean way
> of doing things.
So, what's cleaner? What web framework do you know of that doesn't use
reflection, doesn't use XML configurations and doesn't do explicit mapping?
> Can be ok for a couple of methods but it can be
> really ugly with more than that.
>
> So, is there any other way ?
>
There are numerous ways to associate snippets globally or with a particular
page. If you could talk about your goals or alternatively the way your
favorite web framework does things, that would be a lot more helpful.
Thanks,
David
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
Re: [Lift] Snippet with no reflection an no massive case statement
So you don't want to write any explicit mapping, and you don't want to use reflection??? How would you propose Lift know what your asking for? Im afraid voodoo is not yet compatible with the JVM ;-) Cheers, Tim On 9 Feb 2010, at 16:54, Hugo Palma wrote: > I just read http://wiki.github.com/dpp/liftweb/about-snippets and i > have the following question: > > So is really the only way to avoid having a reflection call every time > you use a snippet to use a DispatchSnippet with a case statement for > every method ? > It's just that i don't really think that the case is a very clean way > of doing things. Can be ok for a couple of methods but it can be > really ugly with more than that. > > So, is there any other way ? > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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] Snippet with no reflection an no massive case statement
I just read http://wiki.github.com/dpp/liftweb/about-snippets and i have the following question: So is really the only way to avoid having a reflection call every time you use a snippet to use a DispatchSnippet with a case statement for every method ? It's just that i don't really think that the case is a very clean way of doing things. Can be ok for a couple of methods but it can be really ugly with more than that. So, is there any other way ? Thanks. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Welcome javier Goday to the Lift committers
Welcome Javier! - a wild crowd member On 09/02/10 9:39 PM, David Pollak wrote: Folks, Please join me in welcoming Javier Goday to the Lift committers. Javier wrote the Lift LDAP module and now that he's a committer, he can make the LDAP module part of the official Lift distribution (and the crowd goes wild). Welcome Javier!! Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Welcome javier Goday to the Lift committers
w00t; bring on the record love... Welcome Javier. Cheers, Tim On 9 Feb 2010, at 16:09, David Pollak wrote: > Folks, > > Please join me in welcoming Javier Goday to the Lift committers. Javier > wrote the Lift LDAP module and now that he's a committer, he can make the > LDAP module part of the official Lift distribution (and the crowd goes wild). > > Welcome Javier!! > > Thanks, > > David > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Mapped(Date)(Time) formatter/parser
Wait--are you saying TimeHelpers should use ConversionRules and ConversionRules should *not* reference TimeHelpers? If so it would involve a lot of refactoring, although I think I hear where you're coming from. I'll try to push the wip-nafg-date branch a bit later. What time zone are you in? - Jeppe Nejsum Madsen wrote: Naftoli Gugenheim writes: > Any thoughts on this? > Basically, to restate the questions in a different way. > - I would like to add overridable methods to MappedDate/Time/DateTime, to > allow controlling the way they parse and format strings. > - Do I need a new 'format' method to controll conversion to a string? Maybe > just leverage toString? I think toString is fine > - Until now there were two places in Mapped(Date)(Time) where parsing > occurred. setFromAny used LiftRules.parseDate, while buildSetStringValue etc. > used TimeHelpers.toDate. Should use same mechanism > - Do we need methods like setFromAny and TimeHelpers.toDate, which take an > Any and pattern match on several types of inputs? Isn't that very un-typesafe? > - Why the inconsistency between setFromAny and buildSetStringValue? Should > both use ConversionRules? Should both use toDate which should use > ConversionRules? > - Should anything in TimeHelpers use ConversionRules? (After all, > ConversionRules uses TimeHelpers, and two-way dependencies are probably > undesirable.) Should ConversionRules be in util rather than webkit? I don't know why things are as they are, but going forward, my assumption is this: - If I change date/time parsing in ConversionRules, this changes all the places where "default" date/time parsing to/from the UI takes place - I think this also goes for TimeHelpers. I see this as a higher level abstraction (the Helpers) on lower level code (ConversionRules), not the other way around - There can be still be specific date formats (ie internetDate) that is being used for API level formatting. /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Welcome javier Goday to the Lift committers
Welcome Javier! :) On 09/02/2010, at 17.09, David Pollak wrote: > Folks, > > Please join me in welcoming Javier Goday to the Lift committers. Javier > wrote the Lift LDAP module and now that he's a committer, he can make the > LDAP module part of the official Lift distribution (and the crowd goes wild). > > Welcome Javier!! > > Thanks, > > David > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Welcome javier Goday to the Lift committers
Welcome! - David Pollak wrote: Folks, Please join me in welcoming Javier Goday to the Lift committers. Javier wrote the Lift LDAP module and now that he's a committer, he can make the LDAP module part of the official Lift distribution (and the crowd goes wild). Welcome Javier!! Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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] Welcome javier Goday to the Lift committers
Folks, Please join me in welcoming Javier Goday to the Lift committers. Javier wrote the Lift LDAP module and now that he's a committer, he can make the LDAP module part of the official Lift distribution (and the crowd goes wild). Welcome Javier!! Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Comet shutdown?
On Tue, Feb 9, 2010 at 3:28 AM, Adam Warski wrote: > Hello, > > I'm playing with comet support in lift, following the example from the > book, and it works fine except for shutting down. > I close the browser window where the page with the comet client was open > and I would expect that at some point shortly after that the localShutdown > method should be called. > > However this doesn't happen (at least didn't happen in the last 10 > minutes). Only when I shutdown the container, I see that the shutdown method > was called. > > A CometActor has a lifespan of the session, not a particular page. The same component may be visible on many different pages. The same component may receive messages from external source, even when the component is not being displayed. The CometActor is a much more pure (in the Smalltalk sense) implementation of MVC than anything else on the web. > Is there some config to make the clients shutdown after the page > referencing them is no longer open? > If you want a CometActor to shut down if it has not appeared on any page for a certain period of time, you can override timespan = Full(2 minutes) in the CometActor. Thanks, David > > -- > Adam Warski > http://www.warski.org > http://www.softwaremill.eu > > > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] CRUDify Customized Access Control Issues
On 9 February 2010 16:04, Jeppe Nejsum Madsen wrote: >>> >>> [...] >>> >>> I suggest you upgrade to 2.0-SNAPSHOT (or M1}, much improved :-) >> >> Am definitely going to give that a spin (wanted to get a better feel >> of Lift in general before it). >> BTW, how "safe" is it to use M* resp. SNAPSHOT releases? > > The milestones are fairly safe. I can only recall one that didn't work > as expected. Snapshots are mostly fine, with an occasional breakage. > > We're running SNAPSHOT on our production site and I can only recall a > few situations where deployment failed, and none where functionality > was compromised Thanks for info, good to know. Going to upgrade to 2.0-M1 (or at least the latest 1.1 one) ASAP. -- Robert -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] CRUDify Customized Access Control Issues
On Tue, Feb 9, 2010 at 2:51 PM, Robert Thurnher wrote: > On 9 February 2010 13:46, Jeppe Nejsum Madsen wrote: >> Robert Thurnher writes: >> >>> >>> [...] >>> >>> Currently, I'm having some issues w/ getting customized page access >>> control of CRUDified models to work properly. Unfortunately, I wasn't >>> able to figure them out solely by reading documentation, code and >>> previous list threads. >>> I'm using lift-core 1.0.2 >> >> I suggest you upgrade to 2.0-SNAPSHOT (or M1}, much improved :-) > > Am definitely going to give that a spin (wanted to get a better feel > of Lift in general before it). > BTW, how "safe" is it to use M* resp. SNAPSHOT releases? The milestones are fairly safe. I can only recall one that didn't work as expected. Snapshots are mostly fine, with an occasional breakage. We're running SNAPSHOT on our production site and I can only recall a few situations where deployment failed, and none where functionality was compromised /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Support for page and snippet level localization
Sorry Tim but i don't quite understand what you mean by "page is scoped to a single snippet" and that invalidates that you have a resource bundle per page. Sorry is this is clear to everyone else but i'm new with Lift so i'm still grasping basic concepts. On Feb 8, 10:49 pm, Timothy Perrett wrote: > That wouldn't work for Lift as it assumes a page is scoped to a single > snippet. It works with Tapestry because its an MVC framework. > > Lift is *not* MVC. > > Have you seen LiftRules.resourceBundleFactories ? > > Cheers, Tim > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: > > > > > Lift only support global resource bundles, i think it would be very > > useful if page and snipped level resource bundles were supported. > > For example, if i have a page "index" it would automatically have > > access to the index.properties_ bundle. Obviously this bundle > > would not be accessible from any other page. > > > I come from an Apache Tapestry background that has page and component > > level localization and it proved very useful. > > > What do you guys think about this ? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] CRUDify Customized Access Control Issues
On 9 February 2010 13:46, Jeppe Nejsum Madsen wrote:
> Robert Thurnher writes:
>
>>
>> [...]
>>
>> Currently, I'm having some issues w/ getting customized page access
>> control of CRUDified models to work properly. Unfortunately, I wasn't
>> able to figure them out solely by reading documentation, code and
>> previous list threads.
>> I'm using lift-core 1.0.2
>
> I suggest you upgrade to 2.0-SNAPSHOT (or M1}, much improved :-)
Am definitely going to give that a spin (wanted to get a better feel
of Lift in general before it).
BTW, how "safe" is it to use M* resp. SNAPSHOT releases?
>> and here's a respective code snippet (from a model mixing in
>> LongCRUDify trait):
>>
>> val loggedIn = If(() => User.loggedIn_?, () =>
>> RedirectResponse("/user_mgt/login"))
>>
>> override def createMenuLoc: Box[Menu] =
>> Full(Menu(Loc("Create "+Prefix, createPath, createMenuName,
>> locSnippets,
>> loggedIn, Loc.Template(createTemplate
>>
>> Now, the compiler complains about a type mismatch at createPath
>> (List[java.lang.String] instead of
>> net.liftweb.sitemap.Loc.Link[net.liftweb.sitemap.NullLocParams]).
>>
>> Probably a solution is obvious, sorry to bother you w/ this in
>> advance. :)
>
> Try to add
>
> import net.liftweb.sitemap.Loc._
>
> to get the implicits in Loc.
Thanks, that did the trick (only imported Loc.If before). :)
-- Robert
> /Jeppe
--
http://soup.robert42.com/
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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: Facebook Application
Hi,
I'll definitely take a look. But I think FB connect is not applicable
for our use..
Here a simple version of the use:
- We have a Lift application providing a RESTfull JSON API for our
clients. Through that API a client application can share a photo to
Facebook
- We have a Web client for the API provided by the Lift server looming
on a different machine. That client does the FB login in order to get
a token for the user.
- That token is sent to the Lift server which uses it to create a new
client (val client = FacebookClient.fromAuthToken(authToken).get)
- When the user shares a photo through our API that fb client is used
to upload the photo to Facebook
On Feb 9, 6:06 am, Jonathan Hoffman wrote:
> Hi All,
>
> I just created issue #336 to provide a Facebook Connect helper and example
> application. You can take a look at what I've got
> here:http://github.com/dpp/liftweb/commit/3b6686201e3b7f22100e52a04734fd4c...
>
> Leo, if you're trying to use fb connect, hopefully this will help you out (I
> would suggest using connect rather than redirecting to FB)
>
> Will push out to master pending your comments and RB.
>
> - Jon
>
> On Feb 5, 2010, at 10:35 AM, Leo Lännenmäki wrote:
>
> > Hi,
>
> > I have only tried to do a couple of things with the Facebook module
> > (I'm using 2.0-M1) and I have gotten some of the stuff to actually
> > work :)
>
> > Photo upload would be something like this:
>
> > import java.io.File
> > import org.apache.commons.io.FileUtils
> > import net.liftweb.ext_api.facebook._
> > import scala.xml._
>
> > FacebookRestApi.apiKey = "your api key"
> > FacebookRestApi.secret = "secret"
>
> > // Get a user to login to Facebook with a link like
> >http://www.facebook.com/login.php?v=1.0&api_key="your api key"
> > // If you mess around with the Facebook settings you will get FB to
> > // redirect the user back to your app with a token as a query param
>
> > val authToken = "as described previously"
> > val client = FacebookClient.fromAuthToken(authToken).get
> > val photo = new File(...)
> > val bytes = FileUtils.readFileToByteArray(photo)
> > val resp = client !? UploadPhoto("test.jpg", "jpg", bytes)
> > val photoUrl = (resp \\ "link").text
>
> > Getting a list of friends:
> > val resp = client !? GetFriends()
>
> > Some real documentation and examples sure would be nice!
>
> > Leo
>
> > On Feb 3, 9:00 am, celestocalculus
> > wrote:
> >> Hello,
> >> I'm an intermediate lift developer. Suddenly, it has become my first
> >> choice framework for web applications. I really think it's a nice
> >> framework you guys are doing a great job.
> >> I'm new on facebook application development and I have been looking at
> >> the liftweb facebook API. I really don't know how to put this but I'm
> >> just blank, I don't know where to start. I would really appreciate it
> >> if I get a step by step explanation. All the book I got on facebook
> >> apps are on php and I find it difficult to match the php codes to
> >> their corresponding lift counterparts.
>
> >> Please I'll also appreciate sample codes, please let it be step by
> >> step and on point.
>
> >> Thanks in advance.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
Re: [Lift] CRUDify Customized Access Control Issues
Robert Thurnher writes:
> Dear list,
>
> I'm pretty new to Lift (went thru the "getting started" tutorial,
> checked out the book plus its sample app, dived into Lift's source a
> little and am by now tinkering w/ coding up some rather simple first
> apps for further learning etc.).
> So, first of all, I'd like to thank you for this great framework;
> really like it so far.
>
> Currently, I'm having some issues w/ getting customized page access
> control of CRUDified models to work properly. Unfortunately, I wasn't
> able to figure them out solely by reading documentation, code and
> previous list threads.
> I'm using lift-core 1.0.2
I suggest you upgrade to 2.0-SNAPSHOT (or M1}, much improved :-)
> and here's a respective code snippet (from a model mixing in
> LongCRUDify trait):
>
> val loggedIn = If(() => User.loggedIn_?, () =>
> RedirectResponse("/user_mgt/login"))
>
> override def createMenuLoc: Box[Menu] =
> Full(Menu(Loc("Create "+Prefix, createPath, createMenuName,
> locSnippets,
> loggedIn, Loc.Template(createTemplate
>
> Now, the compiler complains about a type mismatch at createPath
> (List[java.lang.String] instead of
> net.liftweb.sitemap.Loc.Link[net.liftweb.sitemap.NullLocParams]).
>
> Probably a solution is obvious, sorry to bother you w/ this in
> advance. :)
Try to add
import net.liftweb.sitemap.Loc._
to get the implicits in Loc.
/Jeppe
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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] Comet shutdown?
Hello, I'm playing with comet support in lift, following the example from the book, and it works fine except for shutting down. I close the browser window where the page with the comet client was open and I would expect that at some point shortly after that the localShutdown method should be called. However this doesn't happen (at least didn't happen in the last 10 minutes). Only when I shutdown the container, I see that the shutdown method was called. Is there some config to make the clients shutdown after the page referencing them is no longer open? -- Adam Warski http://www.warski.org http://www.softwaremill.eu -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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] CRUDify Customized Access Control Issues
Dear list,
I'm pretty new to Lift (went thru the "getting started" tutorial,
checked out the book plus its sample app, dived into Lift's source a
little and am by now tinkering w/ coding up some rather simple first
apps for further learning etc.).
So, first of all, I'd like to thank you for this great framework;
really like it so far.
Currently, I'm having some issues w/ getting customized page access
control of CRUDified models to work properly. Unfortunately, I wasn't
able to figure them out solely by reading documentation, code and
previous list threads.
I'm using lift-core 1.0.2 and here's a respective code snippet (from a
model mixing in LongCRUDify trait):
val loggedIn = If(() => User.loggedIn_?, () =>
RedirectResponse("/user_mgt/login"))
override def createMenuLoc: Box[Menu] =
Full(Menu(Loc("Create "+Prefix, createPath, createMenuName,
locSnippets,
loggedIn, Loc.Template(createTemplate
Now, the compiler complains about a type mismatch at createPath
(List[java.lang.String] instead of
net.liftweb.sitemap.Loc.Link[net.liftweb.sitemap.NullLocParams]).
Probably a solution is obvious, sorry to bother you w/ this in
advance. :)
Thanks,
Robert
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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 committers] A Groovy welcome to James Strachan who has joined the Lift committers
Just bringing this thread that drifted off onto the committers list back here... On 8 February 2010 18:58, Naftoli Gugenheim wrote: > Welcome! > Out of curiosity, what are the advantages of this other templating engine? Probably the Haml site describes it quite well (see the showdown at the bottom)... http://haml-lang.com/ basically its a very concise way of making markup - though its a different kind of templating engine to the one in lift where there is no code at all in a template and you bind via reflection XML elements to functions which then replace elements with values or apply other transformations etc. I've used lots of different template engines over the years; they seem to all have strengths and weaknesses - it mostly depends on what the make up & skills of the team is & how the team work with web designers etc. If I'm on a project where I don't have to chuck templates over a wall to be edited by a web designer I find the Scaml approach a little easier on my brain & fingers with the cost that there's no IDE to render it other than the actual web browser and there's code in the template which can be viewed as a bad thing - YMMV though. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
Re: [Lift] Mapped(Date)(Time) formatter/parser
Naftoli Gugenheim writes: > Any thoughts on this? > Basically, to restate the questions in a different way. > - I would like to add overridable methods to MappedDate/Time/DateTime, to > allow controlling the way they parse and format strings. > - Do I need a new 'format' method to controll conversion to a string? Maybe > just leverage toString? I think toString is fine > - Until now there were two places in Mapped(Date)(Time) where parsing > occurred. setFromAny used LiftRules.parseDate, while buildSetStringValue etc. > used TimeHelpers.toDate. Should use same mechanism > - Do we need methods like setFromAny and TimeHelpers.toDate, which take an > Any and pattern match on several types of inputs? Isn't that very un-typesafe? > - Why the inconsistency between setFromAny and buildSetStringValue? Should > both use ConversionRules? Should both use toDate which should use > ConversionRules? > - Should anything in TimeHelpers use ConversionRules? (After all, > ConversionRules uses TimeHelpers, and two-way dependencies are probably > undesirable.) Should ConversionRules be in util rather than webkit? I don't know why things are as they are, but going forward, my assumption is this: - If I change date/time parsing in ConversionRules, this changes all the places where "default" date/time parsing to/from the UI takes place - I think this also goes for TimeHelpers. I see this as a higher level abstraction (the Helpers) on lower level code (ConversionRules), not the other way around - There can be still be specific date formats (ie internetDate) that is being used for API level formatting. /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
