Hi!
Dan OConnor wrote:
>
> Hi Rickard,
>
> Just some quick thoughts.
>
> Underneath AccountEJB you have an "EJB references" node,
> which has an "EJB reference" node and an "ejb/Customer" node as
> siblings. Can I verify that "EJB reference" actually represents an
> example of some reference and not meta-data? If not, I'm not
> exactly sure what's going on...
Sorry about that. I clicked on "Add EJB reference" but didn't assign it
any name, so the default tree-string is "EJB reference". It *is* a
reference. All children of "EJB references" are jBossEjbReference
instances.
> ---
>
> Presumably, other sub-nodes would represent configuration
> possibilities of other plugins. Beneath "Account EJB" you might
> have "Jaws O/R mapping." One question I have is whether or not
> we should distinguish between plugins at this level of the tree.
Yes, that is the question.
> For instance, in your prototype you've put EJB references directly
> under the bean, and I think you'd also put resource references,
> environment entries, security role references, etc. at this level.
Correct, that was the idea.
> I
> wonder if they shouldn't all be grouped under an "EJB 1.1
> deployment descriptor" node.
That might be confusing..
> The reason I might consider this is that other plugins may also
> have multiple configuration screens that the user might want to
> navigate via tree nodes. For example, an O/R mapping plugin
> might need a screen for column-to-table mappings, a screen for
> relationship join definitions, or whatever. It seems to me they
> should all go under the "Jaws O/R mapping" node beneath
> AccountEJB, rather than as "Jaws Column-to-Table Mappings,"
> "Jaws Relationship Join Definitions," etc.
Ok, now I see what you mean.. hm.. yes.. that's a good point.
It does seem as though the structure of EJX should be changed to the
"object"/"attribute" thing you talked about. And also what Juha talked
about awhile ago (i.e. my choice to use inheritance may not be the best
way to do this).
> The disadvantage is that there is an extra click of the mouse to get
> to all these settings, so it's a question of organization vs.
> navigational convenience. One way to solve this without an extra
> layer in the tree might be simply to make each plugin define its
> own icon.
Yes, that's another possibility.
More comments please :-) (BTW, good ones Dan!)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
