Well you were right, but you then exceptions are for those exceptional
scenarios, and we still want to cater those. I would say just a good
programming practice....
I am sure it shouldnt be that much of an effort to implement what i need,
and hopefully someone has a better suggestion in this case..
jwcarman wrote:
>
> How often does an exception happen? Exceptions are supposed to be
> just that, exceptional. Is it really worth your time/effort to code
> for something that's not going to happen that often?
>
> On Wed, Sep 17, 2008 at 8:16 PM, mfs <[EMAIL PROTECTED]> wrote:
>>
>> Thanks for the followup....
>>
>> I understand what you are saying, but what i am not able to figure out,
>> is
>> the best way to communicate to the Search-Page THAT there was an
>> EXCEPTION
>> in the IDataProvider.iterator() or IDataProvider.size() methods (which
>> contains all the back-end calls and is used/invoked by the DataView
>> before
>> rendering), now as i said i can have an empty-list-iterator (from the
>> iterator method) returned if there is an Exception, but how to program
>> the
>> Page ? for it to populate the corresponding error message in the
>> feedback-panel...
>>
>> Thanks in advance.
>>
>>
>>
>>
>> jwcarman wrote:
>>>
>>> You could just always have a feedback panel on your page and if it
>>> doesn't have anything to show, it'll just be invisible. Then, if
>>> something goes wrong, you just set an error-level message and it'll
>>> show up on your feedback panel (don't forget to add the feedback panel
>>> to your ajax response and tell it to output its markup id :).
>>>
>>> On Wed, Sep 17, 2008 at 7:54 PM, mfs <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Hello Guys,
>>>>
>>>> I am trying to do something similar where i have a DataView (contained
>>>> in
>>>> a
>>>> webmarkupContainer) which shows the results of a search. The whole
>>>> implementation is ajax-based. Attached to the DataView is an
>>>> IDataprovider
>>>> implementation which is responsible for fetching the data from the
>>>> database.
>>>>
>>>> Now i want to add this very feature, where in case of any
>>>> Exception/Error
>>>> in
>>>> the back-end processing (which is invoked by the DataProvider) of the
>>>> search, I would want to add a feedback message on the same search-page,
>>>> without being taken to the internal-error-page. As suggested I can
>>>> certainly
>>>> return an empty-list (from the IDataProvider.iterator()) or size=0
>>>> (from
>>>> the
>>>> IDataProvider.size()) method which would still render the DataView
>>>> component, but i am not sure how to tranform or in other words transfer
>>>> the
>>>> knowledge of this Exception to the Page itself.
>>>>
>>>> One ugly hack could be to pass on the FeedbackMessage Label component
>>>> to
>>>> the
>>>> IDataProvider which based on the success/failure is populated with
>>>> right
>>>> message, and re-render the feedback-panel on every ajax-response, but
>>>> that
>>>> looks ugly, i dont want to couple the UI response to DataProvider which
>>>> ideally should work independently of it.
>>>>
>>>> Please suggest..
>>>>
>>>> Thanks and Regards,
>>>>
>>>> Farhan.
>>>>
>>>> i want to display a feedback message in case there is an error at the
>>>>
>>>> Eelco Hillenius wrote:
>>>>>
>>>>>> The basic question was more if I have understood the requirement to
>>>>>> always add a component if the HTML-template named one.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> If so, if there
>>>>>> was some pattern that had evolved for handling alternate or
>>>>>> error-flows when building the component graph.
>>>>>
>>>>> Alternative flows can be handled using panels or fragments possibly
>>>>> combined with component replacements.
>>>>>
>>>>> As for the error-flow, and I don't really see why:
>>>>>
>>>>> try {
>>>>> ...query the database and build the provider and dataview
>>>>> } catch (SQLException e) {
>>>>> feedback.error("Very bad things happened");
>>>>> // What to do here??
>>>>> }
>>>>>
>>>>> should generate a different component structure rather than an error
>>>>> page.
>>>>>
>>>>> Eelco
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/newbie%3A-best-practice-for-not-rendering-component--tp12070364p19543530.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/newbie%3A-best-practice-for-not-rendering-component--tp12070364p19543753.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/newbie%3A-best-practice-for-not-rendering-component--tp12070364p19545856.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
