[OpenAjaxGadgets] gadget edit mode question

Howard Weingram weingram at tibco.com
Fri Apr 10 13:46:35 PDT 2009


Thanks Jon.

Unfortunately, this doesn't fix the problem, which is that as long as we
allow exceptions to the rule, we have to deal with the exceptions using
special-case logic.


KNOWING WHETHER TO RENDER AN "EDIT" BUTTON

Not all widgets have editable properties, so not all widgets should have
containers/windows/chrome around them that have edit buttons that switch to
edit mode. 

There is currently NO way for the widget to declare whether it wants such a
button or not. Originally, including an edit content block did the trick,
but if most widgets that require preference editing don't have <content
mode="edit"> anymore, the host can't use the presence/absence of <content
mode="edit" to determine what to do. All it can do is run through all of the
properties and see if any of them need user editing (not readonly AND not
designonly AND not transient AND not urlparam AND not subscribe AND etc.),
which is a rather horrid approach.

What I am suggesting in this regard is that we have a very clear way in
widget.xml for the widget to request that the host provide (or not provide)
its generic edit mode.

What I propose is that the widget specify an empty element:

    <content mode="edit" render="host"/>

This tells the host that it is responsible for providing the generic
property sheet. If the widget does NOT provide

    <content mode="edit" render="host"/>

then there should be no user-editable properties and the host SHOULD NOT
provide an edit button or equivalent control that brings up a generic
property editor for the end user.

(If the host does it anyway, then it's no great loss, but the user who
brings up the prop sheet will find that there is nothing to edit, and be
puzzled at the presence of such a useless button).

The mechanism described here will work for other host-rendered modes as
well, if any are added.


EDIT MODE / renderedBy

If we believe that custom edit mode is the wrong direction, then while we
still have a chance (before we have legacy stuff to contend with):

1. We should simply specify that the host is responsible for rendering a
generic edit mode UI.

2. Eliminate renderedBy. Edit is always host-rendered.

3. If a widget REALLY, REALLY, REALLY needs a custom UI for editing
preferences (e.g. it needs to implement a wizard that needs an end user to
provide credentials, then brings in a list of data sources from a protected
server, then lets you pick & configure them... .) then it must implement
this as a custom mode rather than as "edit mode."

4. If we find that life is difficult without custom edit mode UI's, it is
always easy to add such things in a future release. It is much, much harder
to remove such features after we let them slip out in the first release.


HELP MODE

How can the host render help mode content in a generic way? Isn't help
content always widget-rendered? Otherwise, where does the help content come
from? The only possible source is the widget's widget.xml <content
mode="help"> element.



Regards,
Howard


On 4/10/09 12:57 PM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> 
> Hi Howard,
> After long discussion over 2+ years about custom UI for editing properties,
> we have been gravitated towardes a model where the editing tool has final
> say over what appears for edit or help mode. On the IDE side, we have
> pretty much dropped custom edit and help modes. Dreamweaver, for example,
> depends on private namespace elements for custom user interfaces. That
> leaves the mashup case. On the front, we concluded that there will be
> scenarios where the mashup assembly tool might not be able to support the
> widget's custom edit or help modes (i.e., impossible or infeasible to
> implement), or the tool might decide that from a UI perspective it is
> better to force all property editing or help information to come in a
> uniform manner across all widgets. Our assumption is that most widgets will
> not have custom edit modes or custom help modes and instead the majority
> case in the short-term will be widgets that provide only a single CONTENT
> element which is used only for rendering/view mode.
> 
> Jon
> 
> 
> 
> 
>                  
>              Howard Weingram
>              <weingram at tibco.c
>              om>                                                        To
>              Sent by:                  Howard Weingram
>              gadgets-bounces at o         <weingram at tibco.com>,
>              penajax.org               "gadgets at openajax.org"
>                                        <gadgets at openajax.org>
>                                                                         cc
>              04/10/2009 12:03
>              PM                                                    Subject
>                                        Re: [OpenAjaxGadgets] gadget edit
>                                        mode question
>                  
>                  
>                  
>                  
>                  
>                  
> 
> 
> 
> 
> For that matter, host/widget rendering is not specific to edit mode and
> could be done for any mode. I think widget.xml needs to explicitly identify
> the modes and explicitly state whether the host or the widget renders the
> UI
> for each mode.
> 
> Regards,
> Howard
> 
> 
> On 4/10/09 11:56 AM, "Howard Weingram" <weingram at tibco.com> wrote:
> 
>> How does a host know whether a widget is expecting the host to provide a
>> generic property editor in place of a widget-rendered edit mode?
>> 
>> It's easy to see whether the widget itself has an edit mode by looking
> for a
>> widget content block (or maybe not).
>> 
>> But if the widget does not provide an edit-mode content block, how does
> the
>> host decide whether to render a property sheet? Maybe the widget has no
>> editable properties, or maybe it wants an edit property sheet.
>> 
>> Does the host look for the presence of at least one widget property that
>> does NOT have any of the following attributes:
>> 
>> * readonly
>> * designonly
>> * transient
>> * subscribe
>> * urlparams
>> ... and maybe others in the future ...
>> 
>> ?
>> 
>> Can the widget not request (in a more straightforward manner) that the
> host
>> provide such an important service?
>> 
>> Regards,
>> Howard
>> 
>> 
>> --
>> Howard Weingram      650.846.1000
>> Principal Architect  TIBCO Software Inc.
>> 
>> TIBCO PageBus(TM) delivers ultra-lightweight
>> publish-subscribe messaging for mash-ups.
>> Learn more at http://www.pagebus.org
>> 
>> _______________________________________________
>> gadgets mailing list
>> gadgets at openajax.org
>> http://openajax.org/mailman/listinfo/gadgets
> 
> 
> 
> --
> Howard Weingram      650.846.1000
> Principal Architect  TIBCO Software Inc.
> 
> TIBCO PageBus(TM) delivers ultra-lightweight
> publish-subscribe messaging for mash-ups.
> Learn more at http://www.pagebus.org
> 
> _______________________________________________
> gadgets mailing list
> gadgets at openajax.org
> http://openajax.org/mailman/listinfo/gadgets



--
Howard Weingram      650.846.1000
Principal Architect  TIBCO Software Inc.

TIBCO PageBus(TM) delivers ultra-lightweight
publish-subscribe messaging for mash-ups.
Learn more at http://www.pagebus.org



More information about the gadgets mailing list