From: "Peter Donald" <[EMAIL PROTECTED]>
> On Mon, 17 Dec 2001 01:30, Jose Alberto Fernandez wrote:
> > Not that I following too close what you are doing in myrmidon, but
> > wouldn't Task.getName() be associated in peoples minds with Task.setName()
> > ? The later being the method for processing an attribute named "name".
>
> Neither getName() nor setName() will be present in the end Task API (Nor will
> there be setTaskType/getTaskType()). Names are something that a container
> manages and thus the only way for a task to even know about them is to grab
> it from the TaskContext.
>
I am talking about the task's methods, like:
<property name="xyz" value="foo" />
this is provided by a task having methods:
public void setName(String x);
public void setValue(String y);
unless you are changing that.
As I said, I am not following too close, but is your getName() part of the
interface
implemented by tasks? This is what I was trying to point out.
> > In a GUI environment you may have the GUI trying to treat the task
> > as a Bean and hence thinking that getName() and setName() refer to the same
> > value, JavaScript takes the same approach. But here getName() referes to
> > something completely different.
>
> not sure what you mean. There is no public setter or getters for name
> anymore.
>
> > Somehow I think we need to deliniate some pattern to diferentiate general
> > APIs of tasks from the patterns used to define attributes and elements of
> > tasks (manipulated at the XML level) I think that is important to enforce
> > separation between internal, public, and XML accessible APIs.
>
> Personally I think that there should be no internal bits exposed by a Task
> using setters.
>
I am fine with that. Well, I am fine with deliniating an exact separation
between
the internal and external APIs.
Jose Alberto
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
