Re: Overriding WorkflowDescriptor

I added setId/setName methods to StepDescriptor. In general, you can 
modify any lists by using the getter and manipulating them that way.

Eg: step.getActions().add(blahblah);

On Monday, May 19, 2003, at 10:11 AM, Johannes Testori wrote:

>> Hmm, ok, I fixed this. Elements now get initialised in a protected
> init
>> method, and all member fields are protected.
> Thanks.
>> Although to be honest all
>> the methods provided to access the fields should be sufficient that
> you
>> can use the accessors rather than modifying the fields directly.
> I always use accessor if possible but it wasn't possible for subclasses
> of StepDescriptor to set id and name or add actions and permissions.
>
> Yours,
> Hannes
>
> On Monday, May 19, 2003, at 06:14 AM, Johannes Testori wrote:
>
>> Hi!
>>
>> I'm overriding WorkflowDescriptor, StepDescriptor, ... because we have
>
>> to work using a different sepcification of the workflows for our
>> project. It's not very comfortable to override the descriptor classes,
>
>> because
>>
>> 1) all work is done in the constructor: I know I can implement my own
>> constructor or override the constructor and only call super(), but I
>> don't really like this. I would like to have methods like
>> createWorkflow(Element root), createAction(Element action) in
>> WorkflowDescriptor and similar ones in the other descriptor classes
>> that I can easily override.
>>
>> 2) all member variables are private: would be great if they were just
>> protected or if there would be enough setter (e.g. I need to override
>> the id, actions-list, ... in StepDescriptor)
>>
>> I know OSWorkflow is open source and I could just change the source
>> code, but I would like to stay compatible with the current release to
>> avoid problems when a new version is released.
>>
>> Kind regards,
>> Johannes Testori
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: If flattening out C++ or Java code
>> to make your application fit in a relational database is painful,
>> don't do it! Check out ObjectStore. Now part of Progress Software.
>> http://www.objectstore.net/sourceforge
>> _______________________________________________
>> Opensymphony-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: If flattening out C++ or Java code 
> to
> make your application fit in a relational database is painful,
> don't do it! Check out ObjectStore. Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>
>



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge