Re: [BULK] - Re: [Catalyst] flash with DBIC session storage

[Tobias Kremer]

Am 28.07.2007 um 02:26 schrieb Jonathan T. Rockway:


This adds a lot of complexity, though.  Is this really a problem that
your users experience, or is it an artifact of poor load testing
practices?


I think you're right: The error is due to my poor-man's approach of  
load-testing.
I believe that it's very unlikely to happen in a production  
environment with real

users hitting the site.

--Tobias


___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [BULK] - Re: [Catalyst] flash with DBIC session storage

[Jonathan T. Rockway]

On Sat, Jul 28, 2007 at 09:15:36AM +0200, Tobias Kremer wrote:
> I think you're right: The error is due to my poor-man's approach of 
> load-testing.

BTW, how are you invoking ab?  I think each request should get its own
cookie, which means the same id shouldn't be being inserted more than
once.

Finally, you might want to try siege instead of ab.

Regards,
Jonathan Rockway

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Use Undo on A List Apart

[Matthieu Codron]

Hi,

Le 26 juil. 07 à 08:55, Bill Moseley a écrit :


There's a recent article titled "Never Use a Warning When you Mean
Undo" at http://alistapart.com/articles/neveruseawarning.

I'm wondering about the implementation.



I read that too. Interesting, but from what I see undo is not so easy  
to implement.



One option is to create actions for every possible undo operation.
That would mean that each undo operation would generate a specific
link, including request parameters to identify the item that needed to
be, well, undone.

Another possibility would be to generate the code for the undo action
and place it in the session so that there's just an /undo link.  /undo
fetches the code and evals/executes it.  The /undo link would only be
available for a single request after displaying the undo link.


I like more the idea of a generic undo request. This could be part of  
a plugin providing this action and the necessary infrastructure to  
implement the "un-doing" of the action.
This plugin could implement a simple version of the classic Memento  
pattern (http://en.wikipedia.org/wiki/Memento_pattern)


Then you could declare undoable actions like this:

sub delete : Local Undoable {
my ($self, $c) = @_;
...

$c->save_undo( $object );
}

# Actual undo action
sub undo_delete : Private {
  my ($self, $c, $restored_object) = @_;
  ...
  # recreate object from $restored_object
}

The generic undo action would then forward to the above declared  
undo_delete action, restoring the saved object.

This would even perhaps allow multi-level undo.



If the undo link is part of the server response the back button might
lead to a stale undo link.  If that's a problem I suppose could do an
AJAX request to fetch the link to prevent it showing up if using the
back button.



Could be in the plugin too, I guess.

--
Matthieu Codron
[EMAIL PROTECTED]
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Use Undo on A List Apart

[Matt S Trout]

On Sat, Jul 28, 2007 at 01:00:14PM +0200, Matthieu Codron wrote:
> Hi,
> 
> Le 26 juil. 07 à 08:55, Bill Moseley a écrit :
> 
> >There's a recent article titled "Never Use a Warning When you Mean
> >Undo" at http://alistapart.com/articles/neveruseawarning.
> >
> >I'm wondering about the implementation.
> >
> 
> I read that too. Interesting, but from what I see undo is not so easy  
> to implement.
> 
> >One option is to create actions for every possible undo operation.
> >That would mean that each undo operation would generate a specific
> >link, including request parameters to identify the item that needed to
> >be, well, undone.
> >
> >Another possibility would be to generate the code for the undo action
> >and place it in the session so that there's just an /undo link.  /undo
> >fetches the code and evals/executes it.  The /undo link would only be
> >available for a single request after displaying the undo link.
> 
> I like more the idea of a generic undo request. This could be part of  
> a plugin providing this action and the necessary infrastructure to  
> implement the "un-doing" of the action.

I fail entirely to see why this should be a plugin rather than part of the
model you're intending to make mutations upon undoable.

> This plugin could implement a simple version of the classic Memento  
> pattern (http://en.wikipedia.org/wiki/Memento_pattern)

I'd say DBIx-Class-Audit (currently in bast trunk pending more testing)
already implements this pretty well for DBIC models - except it always saves
the appropriate information, saving you needing to call anything at all to
make the undo happen.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical DirectorWant a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [BULK] - Re: [Catalyst] flash with DBIC session storage

[Tobias Kremer]

Am 28.07.2007 um 10:12 schrieb Jonathan T. Rockway:


On Sat, Jul 28, 2007 at 09:15:36AM +0200, Tobias Kremer wrote:

I think you're right: The error is due to my poor-man's approach of
load-testing.


BTW, how are you invoking ab?  I think each request should get its own
cookie, which means the same id shouldn't be being inserted more than
once.


Yep, that was exactly what was causing trouble. I provided a cookie
to give ab access to member-only content.

--Tobias



___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Use Undo on A List Apart

[Matthieu Codron]

Le 28 juil. 07 à 14:05, Matt S Trout a écrit :




I like more the idea of a generic undo request. This could be part of
a plugin providing this action and the necessary infrastructure to
implement the "un-doing" of the action.


I fail entirely to see why this should be a plugin rather than part  
of the

model you're intending to make mutations upon undoable.


Maybe it does not have to be a plugin. But it can't be exclusively in  
the model layer either, I guess? (I fail to see this one)
The original idea was to provide a generic /undo action to perform  
the undo. The idea of tagging actions with a "Undoable" annotation  
was to register the action with the undo framework on the controller  
side, so that /undo knows where to forward the undo command.


The actual undoing could reside in the model.


This plugin could implement a simple version of the classic Memento
pattern (http://en.wikipedia.org/wiki/Memento_pattern)


I'd say DBIx-Class-Audit (currently in bast trunk pending more  
testing)
already implements this pretty well for DBIC models - except it  
always saves
the appropriate information, saving you needing to call anything at  
all to

make the undo happen.



Did not know of that, thanks for the info!

--
Matthieu Codron
[EMAIL PROTECTED]
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Use Undo on A List Apart

[Wade . Stuart]

Matthieu Codron <[EMAIL PROTECTED]> wrote on 07/28/2007 11:22:36 AM:

>
> Le 28 juil. 07 à 14:05, Matt S Trout a écrit :
> >
> >>
> >> I like more the idea of a generic undo request. This could be part of
> >> a plugin providing this action and the necessary infrastructure to
> >> implement the "un-doing" of the action.
> >
> > I fail entirely to see why this should be a plugin rather than part
> > of the
> > model you're intending to make mutations upon undoable.
>
> Maybe it does not have to be a plugin. But it can't be exclusively in
> the model layer either, I guess? (I fail to see this one)
> The original idea was to provide a generic /undo action to perform
> the undo. The idea of tagging actions with a "Undoable" annotation
> was to register the action with the undo framework on the controller
> side, so that /undo knows where to forward the undo command.
>
> The actual undoing could reside in the model.

I do not know how this could be generalized for all apps.  In the simple
cases -- maybe.  Consider the following scenarios that you would need to
handle:

* Change happens,  the updated data affects the next 5 actions (via the
current user or another user(s)) and then the user requests an undo --
hard.  Imagine a change such as a picklist item deletion -- where other
users ordering the bundle that place orders after the fact have a bundle
that is limited via the deletion. admin users goes woops and trys to undo
-- now how do you reconcile the state?

* Change happens from multiple sources creating a complex merge list of
different fields -- "undoing" this in different orders or pieces may leave
the data state in a poor state.


Undo (or at least intelligent undo) is a very hard problem in all but the
simplist of shared applications.

The OK or Cancel button is not there because of lazy programming practices,
it is usually there because you are entering a state where a backout is too
hard to do or just does not make sense because of the context.   You may be
better served just putting in undo actions in the places where the action
makes real sense and ignore a list apart's box top screaming.




>
> >> This plugin could implement a simple version of the classic Memento
> >> pattern (http://en.wikipedia.org/wiki/Memento_pattern)
> >
> > I'd say DBIx-Class-Audit (currently in bast trunk pending more
> > testing)
> > already implements this pretty well for DBIC models - except it
> > always saves
> > the appropriate information, saving you needing to call anything at
> > all to
> > make the undo happen.
> >
>
> Did not know of that, thanks for the info!
>



___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: flash with DBIC session storage

[A. Pagaltzis]

* Jonathan T. Rockway <[EMAIL PROTECTED]> [2007-07-28 02:35]:
> On Fri, Jul 27, 2007 at 11:57:01AM -0700, Mesdaq, Ali wrote:
> > Are you sure that InnoDB would solve this issue? Even if just
> > a row was locked and you have 2 inserts at the exact same
> > time how would that resolve the issue?
> 
> One transaction would succeed and the other would fail. If you
> want different behavior, you'll have to change the isolation
> level (or actualy, in this case, rethink your app).
> 
> It's more of an issue of this:
> 
> User visits page A.
> User visits page B in another tab.
> User submits form A.
> User submits form B.
> A updates the flash.
> B updates the flash.
> Page A2 loads with whatever flash won.
> Page B2 loads with whatever flash won.

Keeping implicit state on the server blows. News at 11.

(The right way: don’t use flash. Put the stuff somewhere
where you can give it a URI and send the user to that
address.)

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: flash with DBIC session storage

[Bill Moseley]

On Sat, Jul 28, 2007 at 11:21:56PM +0200, A. Pagaltzis wrote:
> > User visits page A.
> > User visits page B in another tab.
> > User submits form A.
> > User submits form B.
> > A updates the flash.
> > B updates the flash.
> > Page A2 loads with whatever flash won.
> > Page B2 loads with whatever flash won.
> 
> Keeping implicit state on the server blows. News at 11.
> 
> (The right way: don’t use flash. Put the stuff somewhere
> where you can give it a URI and send the user to that
> address.)

So simple case:  client posts which updates a user "Foo".  You
redirect after post and want to display 'User "Foo" was updated' (or
something you need to store server-side between the post and the
redirect).

What's your approach?  Always pass around a session id in the URL?
On redirects pass an unique id to get at that request-specific
message?

If so, how do you manage orphans, say if the redirect never happens?



-- 
Bill Moseley
[EMAIL PROTECTED]


___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Use Undo on A List Apart

[Matthieu Codron]

I do not know how this could be generalized for all apps.  In the  
simple
cases -- maybe.  Consider the following scenarios that you would  
need to

handle:

* Change happens,  the updated data affects the next 5 actions (via  
the

current user or another user(s)) and then the user requests an undo --
hard.  Imagine a change such as a picklist item deletion -- where  
other
users ordering the bundle that place orders after the fact have a  
bundle
that is limited via the deletion. admin users goes woops and trys  
to undo

-- now how do you reconcile the state?

* Change happens from multiple sources creating a complex merge  
list of
different fields -- "undoing" this in different orders or pieces  
may leave

the data state in a poor state.


Undo (or at least intelligent undo) is a very hard problem in all  
but the

simplist of shared applications.



Undo is not easy to implement when then is shared data (like in your  
examples).
But when it's about a shared application letting multiple users  
manipulate their very own private data, IMHO it's definitely a  
manageable problem.

Rememberthemilk is a good example of this.

The OK or Cancel button is not there because of lazy programming  
practices,
it is usually there because you are entering a state where a  
backout is too
hard to do or just does not make sense because of the context.
You may be
better served just putting in undo actions in the places where the  
action

makes real sense and ignore a list apart's box top screaming.


I agree, not every action is undoable and the article in A List Apart  
goes a bit too far on usability and lacks about feasibility/ 
usefulness. But I still think a common infrastructure could help in  
some cases. Desktop apps have had this kind of functionality for  
years, yet it is not too common in web applications.


--
Matthieu Codron
[EMAIL PROTECTED]




___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/