[jdev] Extension field types for jabber:x:data
stpeter at stpeter.im
Mon Dec 3 14:15:27 CST 2007
Richard Smith wrote:
> Hi guys,
> I've spent a sad weekend lounging around the XEPs looking for a possible
> solution to a niggle I've got.
> Basically, I'm in the process of writing an client/server suite that
> implements a sort of MVC architecture over XMPP.
> In terms of the suite, XMPP makes sense for me since it handles the
> point to point nicely, authentication and discovery... All I really need
> to concentrate on are the specifics of my application server environment
> without faffing around with a new protocol suite (isn't re-use nice).
> I would ideally love to stick to existing XEPs that are in play or
> proposed now.
> While there is an XEP in the process for validation of form data
> [XEP-0122] and presentation/layout at client side [XEP-0141], there is a
> definite lack of useful field types in terms of my application for Data
> Forms at the presentation layer.
> I suppose an example might help explain:
> One thing I need to communicate to my client is specific widget types. I
> have fields within views in my application that need to reference models
> and as such need a specific type of widget displayed on the form for
> this purpose.
> Over the wire, the data will be transmitted as an integer or some other
> field type, however to the end-user, being able to display a widget
> which has a search button next to it, which executes a different form,
> will be of value.
> Additionally, there are other nuances that I would like to handle like
> opening another window/dialogue etc.
> So my questions is thus:
> Is there an XEP I'm missed that defines a protocol in this regard?
> If not, would it be worth me submitting any protocol implementation that
> I come up with, or would this not fall under the pervue of XEPs and be
> more of a custom protocol?
It sounds to me as if perhaps you need an application-specific usage of
XEP-0068 form types (e.g., your field names could use some naming scheme
that makes sense in your application).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev