Hi,
Well, I think you've reached the crux of the issue, which is the question
of what exactly SMW should be in charge of doing and what it shouldn't. If
you view SMW as essentially a library that provides "data storage, data
access, or querying" for MediaWiki - sort of a MySQL for MediaWiki - then
indeed having the Page Schemas dependency is not appropriate. However, I
think it makes more sense to view SMW as an extension that provides a lot
of support related to the storage and querying of data. I can think of a
number of things that SMW does, unrelated to its core goals:
- Helper pages like Special:Properties (though that arguably is part of
core functionality)
- RDF export of data
- The "Powered by SMW" button on the bottom of pages
- The #info tooltip function
- Adding to the Admin Links page (maybe I really should stop mentioning
this one)
- Defining various things related to Semantic Forms - the "Form:"
namespace, the "type" used by special properties like "Has default form".
In addition, I think it could make some sense for SMW in the future to
incorporate any of the following features currently in Semantic Forms:
Special:CreateProperty, Special:CreateTemplate, #arraymap and
#arraymaptemplate. None of those are of course necessary for SMW to
function.
Now, maybe the right solution is to split off all of this extra stuff into
one or more other extensions, as was done with DataValues (and perhaps with
Diff and the rest - I don't know if those started out as SMW code).
Personally, though, I think the better solution is to just view SMW as an
extension that does a lot of things, in the back-end and interface, related
to the storage of semantic data.
It's true that the SMW Page Schemas class doesn't actually contain that
much SMW-specific code (though certainly some of it is SMW-specific) - but,
as I noted, that's really just an accident of history, based on the fact
that creation of property pages and the like is done by Semantic Forms. If
that ever changes, the code in the SMW PS class will look a lot more
SMW-heavy.
As for testing the code - it wasn't quite clear from the way you worded it,
but I assume you're saying that this class is not testable, not that the
presence of this class makes all of SMW not testable. Assuming it's the
former, yes, it would probably require integration testing and not unit
testing, but I'm sure it's all doable in theory.
-Yaron
On Thu, Aug 8, 2013 at 11:47 AM, James HK <jamesin.hongkon...@gmail.com>wrote:
> Hi Yaron,
>
> If we look from a point where we see SMW core being assigned to tasks
> like data storage, data access, or querying then the implementation of
> SMWPageSchemas feels a bit sidetracked to the point where:
>
> For example having code like [1] where $psTemplateField is some kind
> of an object but without specific type hinting it could be anything
> and its dependency is more than vague (from a SMW core point of you it
> is non-existent because any operation that happen an behalf of this
> object is unknown to SMW core).
>
> Which part of SMWPageSchemas is so specific to SMW that it requires
> SMW itself. As far as I understand SMWPageSchemas is mostly doing
> string/array manipulations like [2] of some sort but when it comes to
> property/value access it relies on [3] or [4], meaning that data
> access is not the issue.
>
> SMWPageSchemas acts as a formatter of raw values that PageSchemas can
> present to a "consumer". SMW core doesn't (and it shouldn't) know
> anything about formatting rules that are required by PageSchemas (of
> course now it does because of SMWPageSchemas).
>
> Nothing in the code points to a truly SMW core specific (data storage,
> data access, or query related) task that could not be done by a
> generic object formatter, so why does SMW core has to implement
> something like [5] when the only consumer of the code is the
> PageSchemas extension, making SMW core depending on PageSchemas for
> this specific class (and make it actual not testable because of the
> forced dependency).
>
> [1]
>
> $prop_array = $psTemplateField->getObject('semanticmediawiki_Property');
> if ( empty( $prop_array ) ) {
> continue;
> }
>
> [2]
>
> $typeTag = "[[$hasTypeLabel::$propertyType]]";
> $text = wfMessage( 'smw-createproperty-isproperty', $typeTag
> )->inContentLanguage()->text();
>
> [3] PageSchemas::getValueFromObject( $prop_array, 'name' );
>
> [4] PageSchemas::getValueFromObject( $prop_array, 'Type' );
> $allowedValues = PageSchemas::getValueFromObject( $prop_array,
> 'allowed_values' );
>
> [5] $html_text .= "Type: " . Xml::tags( 'select',
> $propertyDropdownAttrs, $select_body ) . "</p>\n";
>
> Cheers
>
> On 8/8/13, Yaron Koren <ya...@wikiworks.com> wrote:
> > 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
> >
>
--
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
