Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Hey, I concur with James on the points he made. The approach taken would make more sense if SMW was a plug in to PS, as this is what the code makes it out to be. I'd rather see the code be part of PS, and have it only be registered there is SMW is loaded. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- 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=48897031iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
On 08/08/13 13:18, Jeroen De Dauw wrote: Hey, I concur with James on the points he made. The approach taken would make more sense if SMW was a plug in to PS, as this is what the code makes it out to be. I'd rather see the code be part of PS, and have it only be registered there is SMW is loaded. +1 Markus Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- 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=48897031iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- 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=48897031iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] ArrayAccessor
Hey, I'm not sure what the use for the newly introduced ArrayAccessor class is. It seems to not be providing a lot of functionality on top of ArrayObject. And I found that one rarely actually needs the functionality ArrayObject provides. And when one does not need it, it is better to not have it, and stick with the simplest implementation possible. The get method of this class is throwing an InvalidArgumentException when a non-existing element is requested. This is wrong, as the provided argument is not invalid. An OutOfBoundsException would work. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- 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=48897031iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Wow... I don't know if there's ever been such quick consensus on a topic on this list. Evidently that Page Schemas class has been bugging people for a long time. :) Yury wrote: I remember Yaron have explained that it's a legacy remained from some kind of global plan of making PageSchemas the central framework for managing all kinds of extensions. I don't recall ever having said that... not that I understand what it means. I'm not even sure what a global plan is. :) The idea with Page Schemas is that it's a framework for defining a data structure and generating the necessary pages based on that structure - but the specifics of the structure and the page-creation are defined by the set of extensions installed. Now, as was pointed out, all this logic could go into Page Schemas itself, but I think it's a nicer solution to have each extension provide its own logic: - Whenever an extension's data structure details change, it can take care of modifying its Page Schemas code on its own, ensuring that Page Schemas will always (up to a point) work correctly with the current installed version of that extension. - Each extension provides its own i18n messages for the extension-specific text it provides to Page Schemas - I think that's a much nicer solution than having Page Schemas hold a ton of messages that actually relate to the workings of other extensions. - New extensions that want to add their data structures into Page Schemas can do that, and further modify their code, without any coordination with me or whoever is maintaining the PS code at the time. Now, any approach to this kind of thing will have code-compatibility issues, so I shouldn't say that in this current approach the extensions will always work correctly together. If the Page Schemas API changes in any way, then of course the extensions' code will all have to change, which is a downside. 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. My planned changes to the Semantic Drilldown extension, for instance, will require removing some fields from the Semantic Drilldown Page Schemas interface. This is not unique to Page Schemas, by the way - my Admin Links extension does the same thing, and SMW (along with other extensions) also has code specific to Admin Links. Or maybe I shouldn't have said that. :) And there are potentially other extensions that could use the same setup - like an extension that let you configure LocalSettings settings from the web interface. I think the Configure extension, which does that but holds all its settings in one place, would have been a lot stronger if it had used a hook-based system to let each extension define its important settings itself. -Yaron On Thu, Aug 8, 2013 at 8:24 AM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 08/08/13 13:18, Jeroen De Dauw wrote: Hey, I concur with James on the points he made. The approach taken would make more sense if SMW was a plug in to PS, as this is what the code makes it out to be. I'd rather see the code be part of PS, and have it only be registered there is SMW is loaded. +1 Markus Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- 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=48897031iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- 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=48897031iu=/4140/ostg.clktrk ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- 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.
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
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. 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. 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. 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. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- -- 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=48897031iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] ArrayAccessor
Hi,
ArrayAccessor is used in several classes[1] to conveniently access an
array through object methods. Of course one could make use of the
ArrayObject directly but one would need to implement the expectation
handling individually for when an expected element is not accessible.
Accessing an array blindly by the means of checking things manually
like if ( isset( array[$key]) ... ) {} where ArrayAccessor or
ArrayObject allows to focus on the task of accessing a value
$this-has( $key ), $this-get( $key ) instead of checking its
validity and later try to gain access.
I'm not a fan of having something like array( 'beAKey' = 'beAValue' )
being transferred beyond an object that invokes the array. An array
that communicates to the outside of its own instantiation should be
encapsulate in an object that carries the array.
And when one does not need it, it is better to not have it, and stick with
the simplest implementation possible.
If we don't want to use ArrayObject, I might have to create a similar
object handler, as I said before doing array( 'key' = 'value' ) by
hand creates all sorts of problems which starts with the validation,
raising exception, and retrieving of its value.
The get method of this class is throwing an InvalidArgumentException
Fair enough.
[1] Settings, MockObjectBuilder, Collector, ApiRequestParameterFormatter
Cheers
On 8/8/13, Jeroen De Dauw jeroended...@gmail.com wrote:
Hey,
I'm not sure what the use for the newly introduced ArrayAccessor class is.
It seems to not be providing a lot of functionality on top of ArrayObject.
And I found that one rarely actually needs the functionality ArrayObject
provides. And when one does not need it, it is better to not have it, and
stick with the simplest implementation possible.
The get method of this class is throwing an InvalidArgumentException when a
non-existing element is requested. This is wrong, as the provided argument
is not invalid. An OutOfBoundsException would work.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
--
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=48897031iu=/4140/ostg.clktrk
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Hi, On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw jeroended...@gmail.comwrote: 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=48897031iu=/4140/ostg.clktrk___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
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.comwrote:
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
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
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.comwrote:
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.comwrote:
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
