Thanks for all the replies.
I think I have hit my first problem. I have packaged all the code in
their respective functional areas like:
au.com.shoebox.businesslogic
au.com.shoebox.woapplication
I have got the Application and Session classes in the woapplication
package as well as the Main class. When I open Main.wo in WOBuilder, it
does not show Application or Session or any of the instance variables
and methods of the class. I found in the archives about the Application
and Session not showing up and ho to fix it, but I don't know why the
wo's own class is not showing up.
Another thing. I have about 2000 image resources in my application. How
should I manage these in eclipse. Currently they are in folders
"images" and "buttons". Should I create a au.com.shoebox.resources
package and then have them in there? Does this effect WOBuilder in
displaying the images?
Any help is greatly appreciated.
Regards,
Greg
I am already reaping the benefits of eclipse by not having to wait
about 8 minutes for the application to build :-)
On 07/10/2004, at 9:23 PM, Susanne Schneider wrote:
> Hello Greg,
>
> Can't help you with the first part of your question but I will try the
> last ;-)
>
> Greg Hulands schrieb:
>> I remember reading in a post (but I can't seem to find it) that
>> talked about have a tool generate the model classes and then
>> subclassing those classes to put in the business logic. Is this
>> generally the accepted way of doing things? What sort of naming
>> convention do people use eg User and UserLogic or UserCore and User?
> We use a method for separating model-methods from custom logic as
> described in the book "WebObjects 5" (it's a german book, I'm not
> shure if there is an english version available).
>
> It's a bit of tricking java: you have to edit the EOJavaClass.template
> used by the EOModeler so that this tools generates a java-class file
> with an additional non-public interface include with declares all
> model-methods in the same file. The eo-class itself extends not the
> EOGenericRecord (or EOEnterpriseObject) but your custom logic-class.
>
> In your abstract(!) custom logic-class you extends EOGenericRecord
> (EOEnterpriseObject) and implements the Interface. Eclipse doesn't
> like this construction and doesn't recognize the model-methods but
> java is able to deal with this. Outside your eoclasses definitions you
> could ignore the artifical construction and behave as there would be
> only one "normal" eoclass.
>
> It's not an elegant solution and you have to provide a custom logic
> class for every eoclass even if there is no need for custom logic at
> all but it's very convenient: once the template is edited you could
> update your eoclasses through EOModeler every time without the danger
> of loosing any of your custom code.
>
> HTH,
> Susanne
> --
> Susanne Schneider
> secuSuite Development
> Coordinator
>
> iAS interActive Systems
> Gesellschaft fuer interaktive Medien mbH
> Dieffenbachstr. 33 c
> 10967 Berlin
> Germany
>
> fon +49(0)30 69004-143
> fax +49(0)30 69004-101
> mail susanne.schneide..nterActive-Systems.de
> URL http://www.interActive-Systems.de
>
This archive was generated by hypermail 2.0.0 : Thu Oct 07 2004 - 22:12:44 EDT