[OFBiz] Dev - Converting Entity XML tools from jsp to widgets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[OFBiz] Dev - Converting Entity XML tools from jsp to widgets

Jacopo Cappellato
Hi all,

I'm converting the entity XML tools (in the webtools application) from
jsp to widgets: the conversion is rather simple, the jsp file is
substituted bya a screen definition, a bsh script containing all the
java code from the jsp file, and an ftl template.

Everything works fine except one thing: during xml data import (in
xmldsimport.jsp and xmldsimportdir.jsp) if an error is found in the xml
file, i.e.:

reader.parse(url);

the current transaction is marked for roll back (probably by the reader
object) and the whole screen blow up.

Probably a solution could be that of starting a new transaction inside
the jsp template... but I'm not sure.

Your suggestions are welcome.

Jacopo

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Dev - Converting Entity XML tools from jsp to widgets

David E. Jones

Jacopo,

 From this description I'm not quite sure what is going wrong, though  
it sounds like the biggest issue is that the error coming back isn't  
very helpful, is that correct?

Perhaps a good way to work through this is to leave the current page  
in place and submit the new one as an alternate page that can be  
enabled by changing the view-map to point to it instead of the jsp.

-David


On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote:

> Hi all,
>
> I'm converting the entity XML tools (in the webtools application)  
> from jsp to widgets: the conversion is rather simple, the jsp file  
> is substituted bya a screen definition, a bsh script containing all  
> the java code from the jsp file, and an ftl template.
>
> Everything works fine except one thing: during xml data import (in  
> xmldsimport.jsp and xmldsimportdir.jsp) if an error is found in the  
> xml file, i.e.:
>
> reader.parse(url);
>
> the current transaction is marked for roll back (probably by the  
> reader object) and the whole screen blow up.
>
> Probably a solution could be that of starting a new transaction  
> inside the jsp template... but I'm not sure.
>
> Your suggestions are welcome.
>
> Jacopo
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Dev - Converting Entity XML tools from jsp to widgets

Jacopo Cappellato
David,

sorry, I was not clear at all.
The main problem is that, if an error is found parsing the entity xml
file, then the screen is not rendered, instead you get the attached
error page/message.
I think that the problem is that the screen is not rendered because the
screen's transaction has been marked for rollback by the parser... but I
could be wrong.

The problematic code is this (taken from line 152 of xmldsimport.jsp):

try {
     numberRead = reader.parse(url);
} catch(Exception exc) {
     %><div class="tabletext">ERROR: <%=exc.toString()%></div><%
}

That I have simply converted in bsh code in the following way:

try {
     numberRead = reader.parse(fulltext);
} catch(Exception exc) {
     errorMessageList.add("ERROR: " + exc.getMessage());
}

If an exception is thrown by the reader.parse(...) method, instead of
the error message in the screen, I get an error page (see error.GIF).
(I've trown a "bogus exception" from the parse(...) method for debug
purposes).

I've resolved the problem adding a rollback command:

try {
     numberRead = reader.parse(fulltext);
} catch(Exception exc) {
     TransactionUtil.rollback(true, "ERROR: ", exc);
     errorMessageList.add("ERROR: " + exc.getMessage());
}

With this code I get a good error message in the screen (see solution.GIF).

However I don't know if this is a good way of doing things or not.

Jacopo


David E. Jones wrote:

>
> Jacopo,
>
>  From this description I'm not quite sure what is going wrong, though  
> it sounds like the biggest issue is that the error coming back isn't  
> very helpful, is that correct?
>
> Perhaps a good way to work through this is to leave the current page  in
> place and submit the new one as an alternate page that can be  enabled
> by changing the view-map to point to it instead of the jsp.
>
> -David
>
>
> On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote:
>
>> Hi all,
>>
>> I'm converting the entity XML tools (in the webtools application)  
>> from jsp to widgets: the conversion is rather simple, the jsp file  is
>> substituted bya a screen definition, a bsh script containing all  the
>> java code from the jsp file, and an ftl template.
>>
>> Everything works fine except one thing: during xml data import (in  
>> xmldsimport.jsp and xmldsimportdir.jsp) if an error is found in the  
>> xml file, i.e.:
>>
>> reader.parse(url);
>>
>> the current transaction is marked for roll back (probably by the  
>> reader object) and the whole screen blow up.
>>
>> Probably a solution could be that of starting a new transaction  
>> inside the jsp template... but I'm not sure.
>>
>> Your suggestions are welcome.
>>
>> Jacopo
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

error.GIF (17K) Download Attachment
solution.GIF (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Dev - Converting Entity XML tools from jsp to widgets

David E. Jones

Technically no code block should rollback or commit a transaction  
that it didn't begin. It is fine to set the rollbackOnly flag  
anywhere, which is what it is meant for.

What this code should probably do is either not catch the exception  
at all, or catch it and then after logging a debug message just re-
throw the exception.

-David


On Oct 15, 2005, at 2:41 AM, Jacopo Cappellato wrote:

> David,
>
> sorry, I was not clear at all.
> The main problem is that, if an error is found parsing the entity xml
> file, then the screen is not rendered, instead you get the attached
> error page/message.
> I think that the problem is that the screen is not rendered because  
> the
> screen's transaction has been marked for rollback by the parser...  
> but I
> could be wrong.
>
> The problematic code is this (taken from line 152 of xmldsimport.jsp):
>
> try {
>     numberRead = reader.parse(url);
> } catch(Exception exc) {
>     %><div class="tabletext">ERROR: <%=exc.toString()%></div><%
> }
>
> That I have simply converted in bsh code in the following way:
>
> try {
>     numberRead = reader.parse(fulltext);
> } catch(Exception exc) {
>     errorMessageList.add("ERROR: " + exc.getMessage());
> }
>
> If an exception is thrown by the reader.parse(...) method, instead  
> of the error message in the screen, I get an error page (see  
> error.GIF).
> (I've trown a "bogus exception" from the parse(...) method for  
> debug purposes).
>
> I've resolved the problem adding a rollback command:
>
> try {
>     numberRead = reader.parse(fulltext);
> } catch(Exception exc) {
>     TransactionUtil.rollback(true, "ERROR: ", exc);
>     errorMessageList.add("ERROR: " + exc.getMessage());
> }
>
> With this code I get a good error message in the screen (see  
> solution.GIF).
>
> However I don't know if this is a good way of doing things or not.
>
> Jacopo
>
>
> David E. Jones wrote:
>
>> Jacopo,
>>  From this description I'm not quite sure what is going wrong,  
>> though  it sounds like the biggest issue is that the error coming  
>> back isn't  very helpful, is that correct?
>> Perhaps a good way to work through this is to leave the current  
>> page  in place and submit the new one as an alternate page that  
>> can be  enabled by changing the view-map to point to it instead of  
>> the jsp.
>> -David
>> On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote:
>>
>>> Hi all,
>>>
>>> I'm converting the entity XML tools (in the webtools  
>>> application)  from jsp to widgets: the conversion is rather  
>>> simple, the jsp file  is substituted bya a screen definition, a  
>>> bsh script containing all  the java code from the jsp file, and  
>>> an ftl template.
>>>
>>> Everything works fine except one thing: during xml data import  
>>> (in  xmldsimport.jsp and xmldsimportdir.jsp) if an error is found  
>>> in the  xml file, i.e.:
>>>
>>> reader.parse(url);
>>>
>>> the current transaction is marked for roll back (probably by the  
>>> reader object) and the whole screen blow up.
>>>
>>> Probably a solution could be that of starting a new transaction  
>>> inside the jsp template... but I'm not sure.
>>>
>>> Your suggestions are welcome.
>>>
>>> Jacopo
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>>
>> ---------------------------------------------------------------------
>> ---
>>  _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
>
> <error.GIF>
> <solution.GIF>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Dev - Converting Entity XML tools from jsp to widgets

David E. Jones

Jacopo,

Okay, after looking around for a while at this I was trying to figure  
out a way we could generally handle situations like this better, and  
all I can come up with is this: the logic there really should go into  
an event (probably as a service) as it is not data preparation logic.  
If something like this happened in data preparation logic then the  
view wouldn't render successfully and we would want this sort of  
thing to happen.

The only way to get the view to display properly would be to know  
which screen actions are critical and should abort screen rendering  
or which should be ignored and listed as error messages. In general  
that's not such a big deal, but in a case where form submission  
processing is done in the view instead of in an event where it should  
be, we are breaking the design pattern and there is no real way to  
make it work properly.

Does that make sense? So, I guess the solution is to move the import  
logic to a service and mount it as a request event...

-David


On Oct 24, 2005, at 3:29 AM, Jacopo Cappellato wrote:

> Hi David,
>
> The code is now in SVN (thanks for committing it with r. 6007), so  
> you can easily have a look at it (see EntityImport.bsh, line 182).
>
> The code now is:
>
> try {
>     numberRead = reader.parse(fulltext);
> } catch(Exception exc) {
>     TransactionUtil.rollback(true, "ERROR: ", exc);
>     errorMessageList.add("ERROR: " + exc.getMessage());
> }
>
> and, as a result of an exception thrown by the parse(...) method,  
> we get the with-rollback.jpg page (this is a nice error message).
>
> If I change the code to:
>
> try {
>     numberRead = reader.parse(fulltext);
> } catch(Exception exc) {
>     errorMessageList.add("ERROR: " + exc.getMessage());
> }
>
> I get the without-rollback.jpg screen.
>
> If I change the code to not catch the exception:
>
> //try {
>     numberRead = reader.parse(fulltext);
> //} catch(Exception exc) {
>     errorMessageList.add("ERROR: " + exc.getMessage());
> //}
>
> I get the no-catch.jpg screen.
>
> Thanks for your time.
>
> Jacopo
>
> David E. Jones wrote:
>
>> Technically no code block should rollback or commit a transaction  
>> that it didn't begin. It is fine to set the rollbackOnly flag  
>> anywhere, which is what it is meant for.
>> What this code should probably do is either not catch the  
>> exception  at all, or catch it and then after logging a debug  
>> message just re- throw the exception.
>> -David
>> On Oct 15, 2005, at 2:41 AM, Jacopo Cappellato wrote:
>>
>>> David,
>>>
>>> sorry, I was not clear at all.
>>> The main problem is that, if an error is found parsing the entity  
>>> xml
>>> file, then the screen is not rendered, instead you get the attached
>>> error page/message.
>>> I think that the problem is that the screen is not rendered  
>>> because  the
>>> screen's transaction has been marked for rollback by the  
>>> parser...  but I
>>> could be wrong.
>>>
>>> The problematic code is this (taken from line 152 of  
>>> xmldsimport.jsp):
>>>
>>> try {
>>>     numberRead = reader.parse(url);
>>> } catch(Exception exc) {
>>>     %><div class="tabletext">ERROR: <%=exc.toString()%></div><%
>>> }
>>>
>>> That I have simply converted in bsh code in the following way:
>>>
>>> try {
>>>     numberRead = reader.parse(fulltext);
>>> } catch(Exception exc) {
>>>     errorMessageList.add("ERROR: " + exc.getMessage());
>>> }
>>>
>>> If an exception is thrown by the reader.parse(...) method,  
>>> instead  of the error message in the screen, I get an error page  
>>> (see  error.GIF).
>>> (I've trown a "bogus exception" from the parse(...) method for  
>>> debug purposes).
>>>
>>> I've resolved the problem adding a rollback command:
>>>
>>> try {
>>>     numberRead = reader.parse(fulltext);
>>> } catch(Exception exc) {
>>>     TransactionUtil.rollback(true, "ERROR: ", exc);
>>>     errorMessageList.add("ERROR: " + exc.getMessage());
>>> }
>>>
>>> With this code I get a good error message in the screen (see  
>>> solution.GIF).
>>>
>>> However I don't know if this is a good way of doing things or not.
>>>
>>> Jacopo
>>>
>>>
>>> David E. Jones wrote:
>>>
>>>
>>>> Jacopo,
>>>>  From this description I'm not quite sure what is going wrong,  
>>>> though  it sounds like the biggest issue is that the error  
>>>> coming  back isn't  very helpful, is that correct?
>>>> Perhaps a good way to work through this is to leave the current  
>>>> page  in place and submit the new one as an alternate page that  
>>>> can be  enabled by changing the view-map to point to it instead  
>>>> of  the jsp.
>>>> -David
>>>> On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote:
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm converting the entity XML tools (in the webtools  
>>>>> application)  from jsp to widgets: the conversion is rather  
>>>>> simple, the jsp file  is substituted bya a screen definition,  
>>>>> a  bsh script containing all  the java code from the jsp file,  
>>>>> and  an ftl template.
>>>>>
>>>>> Everything works fine except one thing: during xml data import  
>>>>> (in  xmldsimport.jsp and xmldsimportdir.jsp) if an error is  
>>>>> found  in the  xml file, i.e.:
>>>>>
>>>>> reader.parse(url);
>>>>>
>>>>> the current transaction is marked for roll back (probably by  
>>>>> the   reader object) and the whole screen blow up.
>>>>>
>>>>> Probably a solution could be that of starting a new  
>>>>> transaction   inside the jsp template... but I'm not sure.
>>>>>
>>>>> Your suggestions are welcome.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> [hidden email]
>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>>
>>>> -------------------------------------------------------------------
>>>> -- ---
>>>>  _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>>
>>> <error.GIF>
>>> <solution.GIF>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>> ---------------------------------------------------------------------
>> ---
>>  _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
> <no-rollback.JPG>
> <with-rollback.JPG>
> <without-rollback.JPG>
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Dev - Converting Entity XML tools from jsp to widgets

Jacopo Cappellato
David,

thanks for your review and solution.
I'll put this refactorings (moving import logic to services) in my todo
list.

Jacopo

David E. Jones wrote:

>
> Jacopo,
>
> Okay, after looking around for a while at this I was trying to figure  
> out a way we could generally handle situations like this better, and  
> all I can come up with is this: the logic there really should go into  
> an event (probably as a service) as it is not data preparation logic.  
> If something like this happened in data preparation logic then the  view
> wouldn't render successfully and we would want this sort of  thing to
> happen.
>
> The only way to get the view to display properly would be to know  which
> screen actions are critical and should abort screen rendering  or which
> should be ignored and listed as error messages. In general  that's not
> such a big deal, but in a case where form submission  processing is done
> in the view instead of in an event where it should  be, we are breaking
> the design pattern and there is no real way to  make it work properly.
>
> Does that make sense? So, I guess the solution is to move the import  
> logic to a service and mount it as a request event...
>
> -David
>
>
> On Oct 24, 2005, at 3:29 AM, Jacopo Cappellato wrote:
>
>> Hi David,
>>
>> The code is now in SVN (thanks for committing it with r. 6007), so  
>> you can easily have a look at it (see EntityImport.bsh, line 182).
>>
>> The code now is:
>>
>> try {
>>     numberRead = reader.parse(fulltext);
>> } catch(Exception exc) {
>>     TransactionUtil.rollback(true, "ERROR: ", exc);
>>     errorMessageList.add("ERROR: " + exc.getMessage());
>> }
>>
>> and, as a result of an exception thrown by the parse(...) method,  we
>> get the with-rollback.jpg page (this is a nice error message).
>>
>> If I change the code to:
>>
>> try {
>>     numberRead = reader.parse(fulltext);
>> } catch(Exception exc) {
>>     errorMessageList.add("ERROR: " + exc.getMessage());
>> }
>>
>> I get the without-rollback.jpg screen.
>>
>> If I change the code to not catch the exception:
>>
>> //try {
>>     numberRead = reader.parse(fulltext);
>> //} catch(Exception exc) {
>>     errorMessageList.add("ERROR: " + exc.getMessage());
>> //}
>>
>> I get the no-catch.jpg screen.
>>
>> Thanks for your time.
>>
>> Jacopo
>>
>> David E. Jones wrote:
>>
>>> Technically no code block should rollback or commit a transaction  
>>> that it didn't begin. It is fine to set the rollbackOnly flag  
>>> anywhere, which is what it is meant for.
>>> What this code should probably do is either not catch the  exception  
>>> at all, or catch it and then after logging a debug  message just re-
>>> throw the exception.
>>> -David
>>> On Oct 15, 2005, at 2:41 AM, Jacopo Cappellato wrote:
>>>
>>>> David,
>>>>
>>>> sorry, I was not clear at all.
>>>> The main problem is that, if an error is found parsing the entity  xml
>>>> file, then the screen is not rendered, instead you get the attached
>>>> error page/message.
>>>> I think that the problem is that the screen is not rendered  
>>>> because  the
>>>> screen's transaction has been marked for rollback by the  parser...  
>>>> but I
>>>> could be wrong.
>>>>
>>>> The problematic code is this (taken from line 152 of  xmldsimport.jsp):
>>>>
>>>> try {
>>>>     numberRead = reader.parse(url);
>>>> } catch(Exception exc) {
>>>>     %><div class="tabletext">ERROR: <%=exc.toString()%></div><%
>>>> }
>>>>
>>>> That I have simply converted in bsh code in the following way:
>>>>
>>>> try {
>>>>     numberRead = reader.parse(fulltext);
>>>> } catch(Exception exc) {
>>>>     errorMessageList.add("ERROR: " + exc.getMessage());
>>>> }
>>>>
>>>> If an exception is thrown by the reader.parse(...) method,  instead  
>>>> of the error message in the screen, I get an error page  (see  
>>>> error.GIF).
>>>> (I've trown a "bogus exception" from the parse(...) method for  
>>>> debug purposes).
>>>>
>>>> I've resolved the problem adding a rollback command:
>>>>
>>>> try {
>>>>     numberRead = reader.parse(fulltext);
>>>> } catch(Exception exc) {
>>>>     TransactionUtil.rollback(true, "ERROR: ", exc);
>>>>     errorMessageList.add("ERROR: " + exc.getMessage());
>>>> }
>>>>
>>>> With this code I get a good error message in the screen (see  
>>>> solution.GIF).
>>>>
>>>> However I don't know if this is a good way of doing things or not.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> David E. Jones wrote:
>>>>
>>>>
>>>>> Jacopo,
>>>>>  From this description I'm not quite sure what is going wrong,  
>>>>> though  it sounds like the biggest issue is that the error  coming  
>>>>> back isn't  very helpful, is that correct?
>>>>> Perhaps a good way to work through this is to leave the current  
>>>>> page  in place and submit the new one as an alternate page that  
>>>>> can be  enabled by changing the view-map to point to it instead  
>>>>> of  the jsp.
>>>>> -David
>>>>> On Oct 14, 2005, at 2:36 AM, Jacopo Cappellato wrote:
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm converting the entity XML tools (in the webtools  
>>>>>> application)  from jsp to widgets: the conversion is rather  
>>>>>> simple, the jsp file  is substituted bya a screen definition,  a  
>>>>>> bsh script containing all  the java code from the jsp file,  and  
>>>>>> an ftl template.
>>>>>>
>>>>>> Everything works fine except one thing: during xml data import  
>>>>>> (in  xmldsimport.jsp and xmldsimportdir.jsp) if an error is  
>>>>>> found  in the  xml file, i.e.:
>>>>>>
>>>>>> reader.parse(url);
>>>>>>
>>>>>> the current transaction is marked for roll back (probably by  
>>>>>> the   reader object) and the whole screen blow up.
>>>>>>
>>>>>> Probably a solution could be that of starting a new  transaction  
>>>>>> inside the jsp template... but I'm not sure.
>>>>>>
>>>>>> Your suggestions are welcome.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [hidden email]
>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -- ---
>>>>>  _______________________________________________
>>>>> Dev mailing list
>>>>> [hidden email]
>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> <error.GIF>
>>>> <solution.GIF>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>  _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>
>>
>> <no-rollback.JPG>
>> <with-rollback.JPG>
>> <without-rollback.JPG>
>>
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev