« Return to Thread: Proposed API change

Re: Proposed API change

by Joe Walker-3 :: Rate this Message:

Reply to Author | View in Thread


The notion of close is vital.

The reverse proxy APIs could be a lot better if they could generate scripts at some later date, after the actual invocation.
Also the open/close gives you a notion of atomicity. All the code inside a block should execute or none at all.

Although we could auto-close, I would like people to understand what the block is about.
For the time being, I've added the extra methods to 'Browser', along with a filter method that someone else suggested.

There is another potential benefit to the Runnable idea. *In theory* if you are in a clustered environment, maybe the UI code could be distributed to the node or nodes which are connected to the clients in question.

Joe.


On Wed, May 14, 2008 at 4:11 PM, Mike Wilson <mikewse@...> wrote:
Joe wrote:
> Collection cs = ServerContextFactory.get().getScriptAllSession();
> ServerContextFactory.setScriptEnvironment(cs);
> Util.setValue("id", 42);
> ServerContextFactory.unsetScriptEnvironment();
>
> or maybe we'd prefer:
>
> Collection cs = ServerContextFactory.get().getScriptAllSession();
> ServerContextFactory.withEnvironment(cs, new Runnable() {
>      public void run() {
>          Util.setValue("id", 42);
>      }
> });

That looks like a cool feature. I would prefer something like
the former syntax as inner classes and runnables always get a
bit too intrusive and verbose for my taste.

I would like to see possibilities for a "shorter" syntax than
your example, maybe

 ServerContextFactory.selectAllScriptSessions();
 Util.setValue("id", 42);

so "all sessions" apply to the rest of this call/request and is
then automatically cleared, no "unset" call. If not selecting
script sessions with the first call then the script session
belonging to the current request (if any) would be used by
default.

Best regards
Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


 « Return to Thread: Proposed API change