Hi,
On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw <jeroended...@gmail.com>wrote:
> Hey,
>
> > 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
> API.
>
> 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...
-Yaron
>
>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil. ~=[,,_,,]:3
> --
>
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
