Re: [ExternalModel, NestedModel] Why not include with @id, @src and @ref?

Hi John,

> What if one of the separations of concern is to write the XForms submissions
> and instances for the web services that the form will use?
>
> In terms of separation of concerns, why would it be any harder to say
> <include src="somebinds.xml"/> than to say <bind src="somebinds.xml"/>?
>
> What if the IDs used in one group of binds conflict with those used in
> another group of binds?  As the repository of forms grows, avoiding ID space
> conflicts among components becomes increasingly tricky and authors tend to
> need an automated way of resolving the conflicts.  If we write a feature
> that does not scale up beyond writing singular forms, then we get limited
> reusability.

Right.

But in the use-cases I've been seeing, the idea is to keep the model
entirely encapsulated.

For example, imagine you have a model that logs in to a system like
Twitter. It contains all of the instances required to handle the
user-name and password, and it also has all of the submissions to do
the login. It is activated by firing an event at the model, and it
reports success or failure by firing an event back.

Now, the nice thing about this:

   <model id="mdl-twitter-login" src="login-to-twitter.xml" />

is that the ID of the model is set in the host document, not the
imported document. This means that the host document can initiate the
login like this:

  <dispatch target="mld-twitter-login' event="do-login" />

and can register for the success and failure events, like this:

  <message ev:event="login-failed" observer="mdl-twitter-login">
    Failed to login to Twitter!
  </message>

and so on.

If you do this:

  <include src="login-to-twitter.xml" />

then the model ID would have to be hard-coded inside the included document.

Note that for me the key notion here is the idea of the model being
encapsulated. We have quite a lot of these kinds of models that fire
events out to notify the host of status, and listen for events to be
told when to do whatever it is that they do. These events are like
public interfaces, but in most cases we treat the internal interfaces
like private class members -- they are not available to the host
document -- which is why I'm not that bothered about the ID fix-up
issue.

I should just say though, that I'm quite happy with XInclude too, and
agree with Erik that for many developers it's already being used to
good effectl.

All I've been imagining is the use of @src as a little bit of
sugar-coating on XInclude; pretty much the same functionality, but
performing an additional step which is to add the attributes from the
host document (like @id, @schema, @functions, etc.).

But as I said, I'm not a fan of the more elaborate 'fixing up'
approach, because I don't think it moves us to a different realm (more
like template processing, rather than simple document importing).

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Tuesday, 16 June 2009 18:14:18 UTC