Is it possible to check an event for a result?

[Bob Silverberg]

Simple example: A reset password form. If a matching email address is found it redirects, via a result, to an event which displays a confirmation message. If a matching email address is not found, it redisplays the form, also via a result.  When that form is redisplayed, it seems to me that the simplest logic to use to determine whether to display an error message to the user would be to check whether the result that caused the form to be redisplayed was added to the event.  But it doesn't seem like that info is available. If I check event.getResults() I get an empty array, so I'm assuming that the results are being cleared prior to displaying the form.

I know I have other options, such as:

1. Set a value into the event to indicate that no matching email address was found.

2. Just check for the existence of the EmailAddress value in the event, as it will only be present if the form was already submitted.

My feeling is that by adding a result to the event, I'm already providing the metadata that I need to make the determination, so why should I have to do #1, and I feel like #2 is indirect.

I am fully prepared to be proven absolutely wrong about this, as is often the case when it comes to me and Model-Glue.

Cheers,

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Ezra Parker]

The results are indeed cleared as one of the last steps in executing
an event handler. If this was not done, the potential problem that
occurs to me is the possibility that results might unexpectedly be
fired in the target event handler if they happened to have the same
name as any of the results that were added by previous event-handlers.

I see your point that a bit of duplication or indirection is necessary
to accomplish this task, but my feeling would be that changing the
behavior to avoid clearing out the results is likely to cause problems
in some applications.

--
Ezra Parker

> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> You received this message because you are subscribed to the Google
> Groups "model-glue" group.
> To post to this group, send email to model...@googlegroups.com
> To unsubscribe from this group, send email to
> model-glue+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en

[Chris Blackwell]

maybe i'm missing something, but I just have my controller set an error message into the event before adding my "EmailNotFound" result.  Then my password reminder form can simply check if there's an error message to display.

2009/11/21 Bob Silverberg <bob.sil...@gmail.com>

--

[Bob Silverberg]

Responses to two emails inline below:

On Fri, Nov 20, 2009 at 11:58 PM, Ezra Parker <ez...@cfgrok.com> wrote:

The results are indeed cleared as one of the last steps in executing
an event handler. If this was not done, the potential problem that
occurs to me is the possibility that results might unexpectedly be
fired in the target event handler if they happened to have the same
name as any of the results that were added by previous event-handlers.

Ah yes, that makes sense. 

 

I see your point that a bit of duplication or indirection is necessary
to accomplish this task, but my feeling would be that changing the
behavior to avoid clearing out the results is likely to cause problems
in some applications.

Right, but maybe, and this is just a Bob-Crazy-Idea-Maybe, what if, in addition to storing the result in _variables.results in the EventContext from whence it's used for processing results, it was also added to a "reporting array" of results in the event as well?  So I wouldn't call getResults() to find out what results have been added to an event, rather I could call event.getValue("addedResults") which would return an array of any and all results that had been added?   And/or perhaps a resultAdded() method that accepts a result name as an argument and returns a boolean.

These would be simple changes that would not affect backward compatibility, but of course if nobody else sees value in this there's no point to adding them.  Considering that this is not something that already exists in the framework, I'm guessing there's a reason for that, but I'm not sure what it is.

On Sat, Nov 21, 2009 at 6:42 AM, Chris Blackwell <ch...@team193.com> wrote:

maybe i'm missing something, but I just have my controller set an error message into the event before adding my "EmailNotFound" result.  Then my password reminder form can simply check if there's an error message to display.

That is another approach that would work, but I'd prefer to keep any display specific code out of my controller, and keep it encapsulated in my view.  I don't want to have to edit a controller to change an error message. So that really leads me back to option 1, which is similar to what you suggest, but rather than setting an error message in the controller, I'd just be setting a value into the event which I would then check in my view.

Again, as this "result checking" mechanism does not currently exist, are there any other ways that people are dealing with this?

--
Bob Silverberg
www.silverwareconsulting.com

[Chris Blackwell]

I totally agree you don't want to have to search through controllers to find error messages, i was simplifying for sake of the example. Its very easy to put all your messages (error or otherwise) into a config file and either have the controller grab the right one, or set an error code which the view can then lookup.  

Chris

2009/11/21 Bob Silverberg <bob.sil...@gmail.com>

Responses to two emails inline below:

On Sat, Nov 21, 2009 at 6:42 AM, Chris Blackwell <ch...@team193.com> wrote:

maybe i'm missing something, but I just have my controller set an error message into the event before adding my "EmailNotFound" result.  Then my password reminder form can simply check if there's an error message to display.

That is another approach that would work, but I'd prefer to keep any display specific code out of my controller, and keep it encapsulated in my view.  I don't want to have to edit a controller to change an error message. So that really leads me back to option 1, which is similar to what you suggest, but rather than setting an error message in the controller, I'd just be setting a value into the event which I would then check in my view.

Again, as this "result checking" mechanism does not currently exist, are there any other ways that people are dealing with this?

--
Bob Silverberg
www.silverwareconsulting.com

--

[Bob Silverberg]

Right. Again, that's pretty much what I described as option 1. My issue is that if I'm already indicating that an error ocurred by adding a result to the event, wouldn't it be nice if I could use that same metadata later in my view, rather than having to add yet another value into my event? It just seems like unnecessary duplication. 

Sent from my iPhone

[Sean Corfield]

On Sat, Nov 21, 2009 at 5:08 AM, Bob Silverberg
<bob.sil...@gmail.com> wrote:
> Right, but maybe, and this is just a Bob-Crazy-Idea-Maybe, what if, in
> addition to storing the result in _variables.results in the EventContext
> from whence it's used for processing results, it was also added to a
> "reporting array" of results in the event as well?  So I wouldn't call
> getResults() to find out what results have been added to an event, rather I
> could call event.getValue("addedResults") which would return an array of any
> and all results that had been added?

And when a redirect is used all that would have to be saved across the
redirect too...

It also ties views directly to controller/XML logic which seems like a
bad idea in my mind.

Having a view displaying an optional error message, pulled from the
event objects seems much better architecture to me. Then the view
neither knows nor cares how it got there.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Bob Silverberg]

On 2009-11-21, at 3:00 PM, Sean Corfield <seanco...@gmail.com> wrote:
>
> And when a redirect is used all that would have to be saved across the
> redirect too...
>

Right. I was only thinking that this would be useful on a do without a
redirect.

> It also ties views directly to controller/XML logic which seems like a
> bad idea in my mind.
>
> Having a view displaying an optional error message, pulled from the
> event objects seems much better architecture to me. Then the view
> neither knows nor cares how it got there.

Yeah, that makes sense. I was just thinking about this some more and
realized that I'd likely set a variable into a result object in my
model, return that to the controller, and put it into the event.

The problem was that I'm just writing the controller and the view
right now and that sent me down the wrong thought path.

Thanks everyone for your responses.

Cheers,
Bob