Application/Session Objects

> You can only call execute: in one
> thread, an await its completion, before issuing another call.
>
> _

Yes, precisely.  And, that's what using the semaphore accomplishes for
me-- makes sure only one thread can be in the execute: method at a time.

Otherwise, I have a single database connection shared among all web threads.

Nevin

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

Nevin Pratt wrote:
>
>> You can only call execute: in one
>> thread, an await its completion, before issuing another call.
>
> Yes, precisely.  And, that's what using the semaphore accomplishes for
> me-- makes sure only one thread can be in the execute: method at a time.

The design philosophy was to implement the protocol to
communicate with the backend - nothing more, nothing less.
Concurrency issues belong elsewhere, where other tradeoffs
may be applicable. Actually, the idea was that there'd be
a connection pool built on top, to hand out connections.
The pool would only guarantee that it would not give out
the connection again, until it was returned. If the recipient
of the connection chose to share it, then it wouldn't be the
pool's responsibility.

BTW, the state machine design was meant to deal with the
non-deterministic order of packets received from the backend,
not to deal with concurrent usage by the client.

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

Martin J. Laubach wrote:
Then I think there's missing application logic,
which may be easier to write with good framework
support. Tightly coupling the domain logic to the
http req/resp is "code smell", IMHO. What happens
when you want to automate a task? Would you then
be forced to mock up an http request in order for
the correct logic to execute.

As for back button, abandoned session, abandoned workflow
- well that's what application logic is for. From the users
point of view, they'll already be seeing navigation boundaries
if #isolate: is used, or if they use the back button more than
the default 10 (or 20?) times. Application logic which
detects the undesired navigation and re-orients the user
seems to be along the same vein.

BTW, I saw a presentation on the Spring Web Flow (Java)
framework, about two weeks ago. They seem to have gone
with a page navigation as state machine approach - i.e.
define which page transitions are allowable and support
that paradigm with a framework. They also mentioned some
continuation support, but I've not investigated further.
Another aside, it seems to me that much of the Spring Framework
is designed to bypass the strong typing of the Java language.

A useful insight they had was that there are two styles of
web applications, which I'll call "brochure" and "workflow".
They were clear that their Spring Web Flow was suitable for
workflows, and somewhat unsuitable for brochures. Just
something to keep in mind.

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

Richard Huxton wrote:

>>
>> Check out http://www.squeaksource.com/OmniSupport.html
>>
>> Unless it's been changed, there should be a subclass of WASession that
>> will give you some idea where you need to plug in.
>
>
> Ta very much - I'll take a look.
>

Note that strategy ODBSSession uses is: 'Commit all changes after current request is processed
and rollback if impossible to commit'. It may be not clear from SQL style programming though.

Connection pool is at ODBSPool

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

stephane ducasse wrote:
>
> On 22 févr. 06, at 18:46, Richard Huxton wrote:
>
>> Seaside looks very interesting, and I like the interactive debugging,
>> closures continuations etc. Hate the Smalltalk syntax,
>
> I do not want to open a can of worms or a language war but help you.

Don't worry about me not liking Smalltalk syntax - I'm a Perl programmer
  :-)

> Here are a bunch of tricks I used to explain the syntax
>
> Just a trick you put [ ] around expressions when you do not know in
> advance the number of times it will be executed.
>     (jj isNil)
>         ifTrue: [ ]
>    
>     4 timesRepeat: [ ]

It's these two I don't like - less because of [ ]  for a closure (good
as anything else - simple so it encourages their use) but the <small
object> <selection-message> <code> pattern. It grates every time I
see/use it.

>     #(1 2 3) do: [:each | ...] separatedBy: [ ]

Whereas this doesn't bother me in the slightest. I think it's the
"complexity" of the object you're dealing with. It feels reasonable to
me to ask a collection to do something for each of its members, less so
for a boolean.

I'm clearly out-voted on this one, since I've been exposed to it for
almost 20 years, haven't changed my mind but am now outnumbered by
generations of object-oriented programmers who came after me.

Ah, now here I think it's too verbose for such a common activity.
Lists/hashes should be as basic as strings/numbers, but like I said, I'm
from a Perl background.

Many of my problems are down to the consistent nature of Smalltalk. I
can see how it's easy to port to a new platform, and it's easy to break
apart someone else's code too. It's just not "elegant" as a language.
The easy access to closures/continuations and the development
environment outweigh that though.

>> the way underscore has been stolen and I'm worried about
>> deployment/management and performance issues. It's early days though,
>> so this is still very much first impressions for me.
>
> In Squeak 3.9 the _ is given back to you :).

Ah, now that is good news. I've gone through and changed my system fonts
already, since I'm referring to external identifiers with underscores
and my eyes keep picking them up as assignments.

> For deployment and management, the gurus around me (lukas and adrian)
> are really enjoying the online, on the fly
> update of code while the system is running....

I'll have to finish my first application and deploy before I can
comment, but it's not quite as command-line friendly as some.

> Now do not hesitate to give feedback and code to the community, we will
> pay attention that it is not lost

It's certainly a friendly and helpful community, which is always
encouraging.

--
   Richard Huxton
   Archonet Ltd

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