[Lift] Re: Tabbed browsing and session state

2009-09-27 Thread tiro


Naftoli,
thanks for providing these insights into the inner workings of
Stateful Snippets. The mapSnippet solution sounds interesting. I knew
that snippets don't live on when not needed, but assumed that IF one
is alive in the current session, you would always get that one
instance. Hence at most one instance would be alive per snippet class
and per session. What you seem to indicate is that the lifecycle is
held together by redirects and such (and therefore page ids) rather
than two requests being in the same session. I will experiment how
that works with tabs. I guess one has to still be very careful since
the user may go from the view initiating a snippet and open several
tabs from there, whereafter you could still get unwanted interference
between the tabs if you don't pay attention.


Marius, thanks for your points
Wizard code
exciting.. since the wizardiness probably won't jump into my eye, if
you happen to stumble on it in the next few days, could you perhaps
post a classname here?

That data needs to be preserved into a RequestVar,
That is precisely what I meant by passing state on from a response to
the next request :-) RequestVars are benign.

AJAX Tabs
Had briefly thought of that. Makes good sense with some types of apps.
In this particular app I've already made other compromises to preserve
standard behavior and let the user bookmark the current URL etc.
Actually things would already be much simpler if browsers allowed you
to address tabs by Javascript (close current tab, jump to search
results tab). One could then keep the results list open in a user-
friendly way. But apparently browsers have been getting quite
restrictive on that, for obvious reasons.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Tabbed browsing and session state

2009-09-27 Thread Timothy Perrett


Please bear in mind that this is *first pass* code and nothing  
production ready.

Cheers, Tim

On 27 Sep 2009, at 16:10, marius d. wrote:

 Please see the lift-wizard project.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Tabbed browsing and session state

2009-09-27 Thread Naftoli Gugenheim

Do you mean multiple browser tabs? They won't interfere, because which stateful 
snippet is used in a given request depends on which is registered in that 
request which depends on which function is called which depends on which 
function id is in the request query parameters which depends on the link that 
was clicked which is generated by the stateful snippet :)
But if one page must link to several pages each with a pre-instantiated snippet 
you must use mapSnippet.
Marius, did David work on lift-wizard since the last time he said he doesn't 
know when he will find time? Also, how would he approach his goal using 
lift-wizard?
 

-
marius d.marius.dan...@gmail.com wrote:


Tiro,

Please see the lift-wizard project.

Br's,
Marius

On Sep 27, 1:33 am, tiro tim.romb...@googlemail.com wrote:
 Naftoli,
 thanks for providing these insights into the inner workings of
 Stateful Snippets. The mapSnippet solution sounds interesting. I knew
 that snippets don't live on when not needed, but assumed that IF one
 is alive in the current session, you would always get that one
 instance. Hence at most one instance would be alive per snippet class
 and per session. What you seem to indicate is that the lifecycle is
 held together by redirects and such (and therefore page ids) rather
 than two requests being in the same session. I will experiment how
 that works with tabs. I guess one has to still be very careful since
 the user may go from the view initiating a snippet and open several
 tabs from there, whereafter you could still get unwanted interference
 between the tabs if you don't pay attention.

 Marius, thanks for your pointsWizard code

 exciting.. since the wizardiness probably won't jump into my eye, if
 you happen to stumble on it in the next few days, could you perhaps
 post a classname here?

 That data needs to be preserved into a RequestVar,

 That is precisely what I meant by passing state on from a response to
 the next request :-) RequestVars are benign.

 AJAX Tabs

 Had briefly thought of that. Makes good sense with some types of apps.
 In this particular app I've already made other compromises to preserve
 standard behavior and let the user bookmark the current URL etc.

Bookmarking URL's would make you loose state unless you preserve that
state in the URL itself. But you're fully aware of this.

 Actually things would already be much simpler if browsers allowed you
 to address tabs by Javascript (close current tab, jump to search
 results tab). One could then keep the results list open in a user-
 friendly way. But apparently browsers have been getting quite
 restrictive on that, for obvious reasons.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Who wants to present Scala or Lift for the Paris JUG ?

2009-09-27 Thread Francois Armand

Hello guys,

The Paris Java User Group ( http://www.parisjug.org ) is interested in a 
Scala presentation. It's a rather young JUG (about 18 months old) but is 
already an unavoidable monthly event.

In general, Paris JUG meeting are composed of two 50 minutes 
presentations in French, separated by an aperitif. There is about 
170~200 people coming to each meeting, going from students to CTO, with 
a fair number of geeks/architects and business people.

I discussed with the organizers, and they are really interested in a 
full meeting around Scala (it seems to be in their hot things list ;). 
So, the idea would be to have a first presentation rather generic of the 
language, like a shorter version of the one I gave to OSSGTP 
(http://www.slideshare.net/fanf42/a-tour-of-scala).

The second one could be directed toward demonstration and practical 
application of Scala, like a presentation of Lift or other Scala 
frameworks / code (XML manipulation, actors, akka, scalatest, sbt, etc) 
in a show me the code way.

I can be in charge of the first part, and I'm looking for a Lift master 
or anybody willing to demonstrate Scala for the second part.

So, if you you are interested, contact me to see what we can do to 
promote Scala in Paris !

-- 
Francois Armand
http://fanf42.blogspot.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Using a nosql database instead of Mapper?

2009-09-27 Thread Rick Richardson

How would I go about creating an alternative database wrapper for use
with Berkely DB JE instead of Mapper+SQL?  Is there something that
describes the methods that Lift expects a model object to have?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Using a nosql database instead of Mapper?

2009-09-27 Thread Naftoli Gugenheim

If you're not using Mapper then there's nothing to worry about. Nothing in 
lift's core (http, util, etc.) depends on Mapper.
If you want to use Mapper with a driver not known by Lift you would probably 
have to supply your own DriverType, if that's possible. But Mapper is based on 
SQL.
On the other hand you can write a new backend for Record, if you don't want to 
use the regular API for your database.


-
Rick Richardsonrick.richard...@gmail.com wrote:


How would I go about creating an alternative database wrapper for use
with Berkely DB JE instead of Mapper+SQL?  Is there something that
describes the methods that Lift expects a model object to have?




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] RFC: Restructuring Lift Codebase

2009-09-27 Thread Indrajit Raychaudhuri

Folks,

As followup to the proposed goal of Keeping lift-core neat and
small, here is the first iteration of the revised structure of Lift
codebase.


liftweb

- lift-core [10]
  - lift-base [02]
  - lift-actor
  - lift-util
  - lift-json [03]
  - lift-webkit [04]
  - lift-testkit [05]

- lift-persistence [06]
  - lift-mapper
  - lift-record
  - lift-jpa

- lift-modules [07]
  - lift-osgi
  - lift-wizard [08]
  - lift-widgets [09]
  - lift-machine
  - lift-textile
  - lift-facebook
  - lift-amqp
  - lift-xmpp
  - lift-openid
  - lift-oauth
  - lift-paypal
  - lift-jta

- lift-archetypes
  - ...

- lift-examples
  - ...

- lift-site [10]

- lift-resources [lift-varia, lift-infra ?] [11]
  - lift-root-model [12]
  - lift-site-skin
  - lift-installer
  - misc config resources (scaladoc, javadoc etc.)

General notes (including some obvious ones):

[A] lift-* prefix looks superfluous, but it's best to have one for all
artifacts that generate jar (packagingjar/packaging). Also Maven
reactor feels happier when artifactId == directory_name (site
generation, scm extrapolation etc., situation might have improved
now).

[B] The top level project categories (lift-core, lift-persistence,
lift-modules etc.) are simple multi-module models at the moment and
not meant to create anything other than pom. Therefore, lift-* prefix
can go away. But they'll have to come back if we plan to generate 'one
jar' in assembly mode per category (lift-core-all.jar, lift-
persistence-all.jar etc.). This could be useful for 'get me
everything, I don't care about size' people. But is it necessary? The
alternative is to have empty 'meta modules' that pull up the necessary
dependencies and can be included by the users in their project (quite
similar to what lift-core does now).

[C] The members in a project category (lift-mapper, lift-record etc.)
would inherit the category model (lift-persistence in case of lift-
mapper, lift-record). Related modules clubbed together helps similar
configuration pulled up to the parent pom (improves DRY-ness). Added
benefit: modules can be developed even outside Lift codebase with the
given parent pom (available in global repo) and the developer won't
have to worry about most of the infra related boilerplate
configurations (couple of config still would need change though).

[D] Presentations and other materials aren't really source code for
inclusion in source repository. Can this go in wiki? (immediate
problem: github doesn't take attachment). Has this been discussed
earlier? They can go as a separate github project too.

[E] The categorization is mostly based on my interpretation as a late
entrant. If there is a different structure that fits the philosophy
better (quite likely), this would get regrouped. (Tim ?)

[F] The modules in a category can be further sub-grouped, but with
caution. Basically, need the right mix between 'flat'-ness and deep
nesting. Thoughts on this?

[G] Each category can eventually be split up into separate projects
and have their own release schedules (less frequent for core, more
frequent for modules etc.). This might be little overkill at the
moment. Just mentioned to enable us mind the long term perspective :)

[H] Other points on the draft hierarchy (see the # in brackets above):

[01] With these members, if lift-core doesn't sound as the right name,
we need the right name. Provided the grouping is right that is.

[02] Base interfaces for Lift (currently present in dpp_wip_actorized)

[03] Doesn't really have to be part of Lift core in current form, but
this is eventually meant to be part of Lift's JS infrastructure (thus
kept here at the moment)

[04] Candidate for decomposition. But kept intact at the moment. Would
be taken up in next pass once the top level reaches steady state. This
could either become a category of its own or a module with submodules.

[05] Little unsure about it's intent and purpose, I could be
completely mis-interpreting this. Thoughts from somebody with more
understanding please :)

[06] Doesn't have to be part of lift-core. Lift applications not using
persistence doesn't have to need this.

[07] Extra stuff, necessary iff one needs. Right now, I am putting
'everything else' here for lack of better place, but I see a scaling
up issue there. This can turn out to be a place for all the 'nowhere
else to go' modules. But we can take it up in next pass. Suggestions?

[08][09] See #04 above. Can be subpackage of lift-webkit eventually

[10] The website! The intent is to bring liftweb.net codebase into the
streamlines structure. Can be deferred if this is not a burning need.

[11] Recommendation for a good name?

[12] The top level pom for Lift project. All models (the categories)
are expected to inherit this. These categories doesn't necessarily
have to belong to the same git repo.


Let the discussion/debate begin!

Cheers, Indrajit

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 

[Lift] Re: Using a nosql database instead of Mapper?

2009-09-27 Thread Timothy Perrett

I'm not familiar with berkly, but I've written my own backend for  
record and it is very, very nice... Highly recomend it.

Cheers

Tim

Sent from my iPhone

On 27 Sep 2009, at 20:39, Naftoli Gugenheim naftoli...@gmail.com  
wrote:


 If you're not using Mapper then there's nothing to worry about.  
 Nothing in lift's core (http, util, etc.) depends on Mapper.
 If you want to use Mapper with a driver not known by Lift you would  
 probably have to supply your own DriverType, if that's possible. But  
 Mapper is based on SQL.
 On the other hand you can write a new backend for Record, if you  
 don't want to use the regular API for your database.


 -
 Rick Richardsonrick.richard...@gmail.com wrote:


 How would I go about creating an alternative database wrapper for use
 with Berkely DB JE instead of Mapper+SQL?  Is there something that
 describes the methods that Lift expects a model object to have?




 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: CometActor timeout problem

2009-09-27 Thread jack

I am still having this problem so I will post a simple example. Say I
want to display a list of the numbers 1 to 100. And suppose I have an
object Foo and a method bar, which takes an integer and returns an
integer. And bar takes about 10 seconds to return. So I want to
display the numbers, run Foo.bar on each of them in the background,
and then update the display via comet to replace each integer with bar
of it. I got the Clock example to work and I think I understand what
is going on there. Could somebody show me how to do this example in
terms of the Clock example? Or just a few lines of code to suggest how
to do it?








On Sep 18, 12:09 pm, marius d. marius.dan...@gmail.com wrote:
 On Sep 17, 11:09 pm,jackjack.wid...@gmail.com wrote:

  I have a CometActor which displays a list of urls and at the same time
  launches a bunch of threads each of which gets information about the
  urls and then puts messages about that information in a Queue. On each
  new tick, the CometActor checks the queue and updates its urls.

  The problem is that I am launching the threads from the CometActor and
  the page is never coming back. It times out.

 So the page never gets rendered? I would recommend using actors and
 not really threads but even with threads it shouldn't impact you. But
 it also depends on what your code does. Can you post a minimalistic
 example?





  Is there some general principle about launching threads from a
  CometActor that might explain this behavior?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: RFC: Restructuring Lift Codebase

2009-09-27 Thread marius d.

Generally I like this structure.Please see my other comments below:

On Sep 27, 3:44 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 Folks,

 As followup to the proposed goal of Keeping lift-core neat and
 small, here is the first iteration of the revised structure of Lift
 codebase.

 liftweb

 - lift-core [10]
   - lift-base [02]
   - lift-actor
   - lift-util
   - lift-json [03]
   - lift-webkit [04]
   - lift-testkit [05]

 - lift-persistence [06]
   - lift-mapper
   - lift-record
   - lift-jpa

 - lift-modules [07]
   - lift-osgi
   - lift-wizard [08]
   - lift-widgets [09]
   - lift-machine
   - lift-textile
   - lift-facebook
   - lift-amqp
   - lift-xmpp
   - lift-openid
   - lift-oauth
   - lift-paypal
   - lift-jta

 - lift-archetypes
   - ...

 - lift-examples
   - ...

 - lift-site [10]

 - lift-resources [lift-varia, lift-infra ?] [11]
   - lift-root-model [12]
   - lift-site-skin
   - lift-installer
   - misc config resources (scaladoc, javadoc etc.)

 General notes (including some obvious ones):

 [A] lift-* prefix looks superfluous, but it's best to have one for all
 artifacts that generate jar (packagingjar/packaging). Also Maven
 reactor feels happier when artifactId == directory_name (site
 generation, scm extrapolation etc., situation might have improved
 now).

 [B] The top level project categories (lift-core, lift-persistence,
 lift-modules etc.) are simple multi-module models at the moment and
 not meant to create anything other than pom. Therefore, lift-* prefix
 can go away. But they'll have to come back if we plan to generate 'one
 jar' in assembly mode per category (lift-core-all.jar, lift-
 persistence-all.jar etc.). This could be useful for 'get me
 everything, I don't care about size' people. But is it necessary? The
 alternative is to have empty 'meta modules' that pull up the necessary
 dependencies and can be included by the users in their project (quite
 similar to what lift-core does now).

 [C] The members in a project category (lift-mapper, lift-record etc.)
 would inherit the category model (lift-persistence in case of lift-
 mapper, lift-record). Related modules clubbed together helps similar
 configuration pulled up to the parent pom (improves DRY-ness). Added
 benefit: modules can be developed even outside Lift codebase with the
 given parent pom (available in global repo) and the developer won't
 have to worry about most of the infra related boilerplate
 configurations (couple of config still would need change though).

 [D] Presentations and other materials aren't really source code for
 inclusion in source repository. Can this go in wiki? (immediate
 problem: github doesn't take attachment). Has this been discussed
 earlier? They can go as a separate github project too.

 [E] The categorization is mostly based on my interpretation as a late
 entrant. If there is a different structure that fits the philosophy
 better (quite likely), this would get regrouped. (Tim ?)

 [F] The modules in a category can be further sub-grouped, but with
 caution. Basically, need the right mix between 'flat'-ness and deep
 nesting. Thoughts on this?

 [G] Each category can eventually be split up into separate projects
 and have their own release schedules (less frequent for core, more
 frequent for modules etc.). This might be little overkill at the
 moment. Just mentioned to enable us mind the long term perspective :)

 [H] Other points on the draft hierarchy (see the # in brackets above):

 [01] With these members, if lift-core doesn't sound as the right name,
 we need the right name. Provided the grouping is right that is.

 [02] Base interfaces for Lift (currently present in dpp_wip_actorized)

I'm not sure about base interfaces for lift ...


 [03] Doesn't really have to be part of Lift core in current form, but
 this is eventually meant to be part of Lift's JS infrastructure (thus
 kept here at the moment)

JSON should not only be part of JS stack as it is used in many
contexts for REST API's. So I'd keep it in the core,


 [04] Candidate for decomposition. But kept intact at the moment. Would
 be taken up in next pass once the top level reaches steady state. This
 could either become a category of its own or a module with submodules.

Why splitting it up? .. .the webkit if the very core of lift.


 [05] Little unsure about it's intent and purpose, I could be
 completely mis-interpreting this. Thoughts from somebody with more
 understanding please :)



 [06] Doesn't have to be part of lift-core. Lift applications not using
 persistence doesn't have to need this.

I definitely agree.


 [07] Extra stuff, necessary iff one needs. Right now, I am putting
 'everything else' here for lack of better place, but I see a scaling
 up issue there. This can turn out to be a place for all the 'nowhere
 else to go' modules. But we can take it up in next pass. Suggestions?

 [08][09] See #04 above. Can be subpackage of lift-webkit eventually

I would definitely keep them separated