On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw <email@example.com>
> Wow... I don't know if there's ever been such quick consensus on a topic on this list.
Yes, you have won of badge of some sorts :)
> I'm not even sure what a "global plan" is. :)
Ah, of course you would deny your secret plans to take over the world, and then install SMW everywhere.
Well, it's true that I'm constructing a giant laser beam, but it's for, uh, research purposes only. :)
> But on the other hand, I think changes to the data structure are likely
to happen on a much more frequent basis than changes to the Page Schemas
This might be true. However if you look at what is actually happening, nothing of this nature has changed since the introduction of the class.
That's true, although things do change - as I noted, there's a plan for the Semantic Drilldown structure to change sometime in the near future. And the SMW setup could potentially change as well. A big part of the reason why there haven't been any changes in the SMW class is that SMW doesn't do any page-generation itself - Semantic Forms takes care of some of the things that perhaps ideally SMW itself should hold, like the CreateProperty and CreateTemplate special pages. (That's a subject for another thread, though - I don't mean to derail this one.) So it's the SF PS code that changes if there's a change to the SMW data structure setup, like the recent removal of the "String" property. But if the helper forms for creating properties and/or SMW-based templates were to ever move to SMW, SMW's Page Schemas class would most likely start needing updates on any data structure change. Which I think is as it should be.
From an SMW maintenance perspective, it is not nice to have this code in there. And having this "semi dependency" on PS makes things more fuzzy for both users and devs.
I don't actually see it as confusing or difficult, personally - I think it's a nice, modular approach to creating an interface that involves the behavior of a bunch of extensions. As I noted, Admin Links takes the same approach, and I don't think that one has caused any confusion (though perhaps I shouldn't keep mentioning it :) ).
A third option is to have a PSSMW extension that depends on both SMW and PS, and contains the code in question. This of course comes with its own set of tradeoffs. Presumably one such extension can be made to hold PS all code for SMW and SMW extensions.
Oh... adding another extension sounds like a worst-case scenario. Especially if the goal is to prevent user confusion...