Session accesible from the model of an application

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>     has anybody found useful to have accesible the session from the model of
> an application?

See how #session is implemented in WAComponent and copy that method to
your model. WAComponent itself does not have a direct reference to the
session.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> >     has anybody found useful to have accesible the session from the
> > model of an application?
>
> See how #session is implemented in WAComponent and copy that
> method to your model. WAComponent itself does not have a
> direct reference to the session.
>
> Lukas
>
Right but it's in WAPresenter. I've forgot I can look there. I supouse it
was the hour ;-) thanks Lukas

  cheers,

Sebastian

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

That's why Hierarchy Browser (and Method Finder) are useful. As a
eye-candy thing, I use a special session to generate a random number and
so, my application can get a new background image identified by
this number on each session. So the user can notice more visually that a
new session as started because the website doesn't look like the
previous one.

Ramon Leon explains on onsmalltalk.com how to use #session in his
excellent glorp example.

--
Martial

Sebastian Sastre a écrit :
| > >     has anybody found useful to have accesible the session from the
| > > model of an application?
| >
| > See how #session is implemented in WAComponent and copy that
| > method to your model. WAComponent itself does not have a
| > direct reference to the session.
| >
| > Lukas
| >
| Right but it's in WAPresenter. I've forgot I can look there. I supouse it
| was the hour ;-) thanks Lukas
|
|   cheers,
|
| Sebastian
|
| _______________________________________________
| Seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Sebastian, I have pondered this question for reaching my Magma
session from my domain without diectly referencing them.

  http://wiki.squeak.org/squeak/5605

The ideas may translate to Seaside or other "sessions"..

Also, with Magma, you *can* now reference the session in the domain if
you want.  It is always populated with whatever session materialized
it.  I'm not inclined to do this myself, but others have been, so I
recently made it work.  Maybe the same can be accomplished for
Seaside..?

 - Chris

On 4/16/07, Sebastian Sastre <[hidden email]> wrote: _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/4/18, Chris Muller <[hidden email]>:
Seaside uses something similar since a long time. A notification
(resumable exception):
WACurrentSession value
gives you the current session.

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi!

> Hi Sebastian, I have pondered this question for reaching my Magma
> session from my domain without diectly referencing them.
>
>   http://wiki.squeak.org/squeak/5605
>
> The ideas may translate to Seaside or other "sessions"..

Just a note - in Gjallar we use DynamicBindings for this. So deep in the
domain model we can type "Q2Session current" (a subclass of WASession
which in turn holds a MagmaSession) and then do what we like with it.

A simpler approach avoiding DynamicBindings would be using the pattern
that is used in Seaside itself (or Pier) by subclassing Notifier etc.

Or did I misunderstand the question?

In Gjallar we fire off Magma transactions deep inside the domain model -
due to the design of Gjallar where we package all db modifications in
Q2Txn objects thus saving an endless history of all deltas (similar to
Prevayler etc).

regards, Göran

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Göran Krampe wrote: Try implementing a Registry (see "Registry Pattern") and if you are
using magma in single-user mode, implement a singleton on the magma
session. I opted to subclass MagmaSession and provide an #instance method:

instance
    ^Session ifNil:
         [Session _ (MagmaSession openLocal: '/path') connectAs: 'user']



Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi!

> Try implementing a Registry (see "Registry Pattern") and if you are
> using magma in single-user mode, implement a singleton on the magma
> session. I opted to subclass MagmaSession and provide an #instance method:
>
> instance
>     ^Session ifNil:
>          [Session _ (MagmaSession openLocal: '/path') connectAs: 'user']

Ehmmm... the problem here (I presume) is that there are multiple
MagmaSessions being used in different Processes. So you need to get hold
of the *correct* MagmaSession - not just a singleton.

regards, Göran

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Göran Krampe wrote: Hence the "if you are using single user mode" :) The singleton is merely
for that. Use a Registry to contain the sessions, then pass that around
your model/application.


Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

[hidden email] wrote on 18.04.2007 13:09:32:

> Göran Krampe wrote:
> > Hi!
> >
> >
> >> Try implementing a Registry (see "Registry Pattern") and if you are
> >> using magma in single-user mode, implement a singleton on the magma
> >> session. I opted to subclass MagmaSession and provide an #instance
method:
> >>
> >> instance
> >>     ^Session ifNil:
> >>          [Session _ (MagmaSession openLocal: '/path') connectAs:
'user']
> >>
> >
> > Ehmmm... the problem here (I presume) is that there are multiple
> > MagmaSessions being used in different Processes. So you need to get
hold
Hi,

I recently implemented a facade for this problem along the following
lines:

If there is a seaside session, fetch the DB connection from the seaside
session, otherwise fetch it from some connection holding singleton
independent of Seaside.
This way one can write stand alone tests using the same interface/facade
to the DB as the real application, as the both talk to the switching
facade. As a downside you need to run your tests then while _not_ having a
seaside session running of course.

Hope this helps,

Markus


>
>
> Pinesoft Computers are registered in England, Registered number:
> 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts,
EN8 7EA
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside