On 24 May 00, at 21:35, Juha Lindfors wrote:
> >I think your point is good about the number of tabs you can have
> >before the user interface becomes unintuitive. Would it be
> >mitigated by my suggestion to let the user control the tabs (i.e. the
> >views) dynamically?
>
> What exactly do you mean by this?
Hi Juha,
A user that doesn't use CMP wouldn't need to see a tab related to
Jaws, or Castor, or anything else. If he or she wanted to use Jaws
for a specific bean, he or she would choose "Add Jaws View" from
the "Plugin" menu, or something like that. And we would
dynamically load the plugin and add a tab (or tabs) to the current
view.
>
>
> >Otherwise, I see two possibilities. The first is that my conceptual
> >division is wrong in terms of the user-interface. We could consider
> >inserting plugin-specific branches into the tree. For instance, the
> >user might be able to insert a new Jaws node into a CMP bean.
> >Then, when he or she clicked on that node, a view would open up
> >that would allow him or her to configure the Jaws mapping.
>
> Hmm.. there might be something here too. My initial thinking was that one
> JAWS configuration will do for all entities, but of course that was wrong.
>
> In that case, the assembly/bean structure on a tree would be sufficient I
> think. Yet we might still end up with a lot of tabs... how many different
> plugins can you see for one bean, for example?
>
Well, the simplest case would be one, because we should let the
user deploy a bean with only the information in the deployment
descriptor. I think the most common case would be three:
deployment descriptor, basic JBoss-specific settings, and O/R
mapping for container-managed persistence. (I think JBoss-
specific settings should be divided between at least two plugins,
basic--e.g. JNDI mappings--and advanced--e.g. pool configuration.)
Worst-case scenario would probably be five or six for EJBs alone,
thinking off the top of my head: deployment descriptor, basic
container settings, advanced container settings, O/R mapping,
security configuration, and whatever else I missed. Of course, EJX
should probably be a J2EE tool, not an EJB tool, given the
ambitions of this project. So add some more to the list to
configure web settings, JMS settings, etc.
-Dan
