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
>
------------------------------------------------------------------------------
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
