Moin Greg,
due to some limitations in the PB.project support in WOBuilder I would
recommend to keep App, Session and main in the default package.
About your resources. Copy them into the project. Right click on the
buttons folder and choose "Include as WebServer Resources". Do the same
for images.
After that. WOBuilder should display the images.
Ulrich
Am 08.10.2004 um 04:12 schrieb Greg Hulands:
> 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 : Mon Oct 11 2004 - 15:04:00 EDT