Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Hey, Yaron, I disagree with some of the points you made here. However taking a step back from this, perhaps its not worth bickering about what is really the best thing to do here if all else where perfect already. Though there is room of improvement here, it hardly seems urgent, and quite far down the priority list. So my vote actually goes for leaving it as it is, and concentrating on more critical todos. 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, I didn't know whether you were serious about splitting off the SMW PS class into its own extension, but clearly you are - and you might want other functionality split off as well, like maybe an #info tag extension. I don't know whether it's worth having a full discussion about the philosophy of extension size on this list - there was a long discussion about this topic on the wikitech-l mailing list last month that covered the main points, which anyone can see here: http://www.gossamer-threads.com/lists/wiki/wikitech/375342 This is a big topic, but I'll just say that the view of MediaWiki extensions as libraries or packages is, in my opinion, not an accurate description. If there were a true package management system for MediaWiki, that everyone could use easily, it might be a different story, but at the moment there isn't. So many people end up maintaining many different versions of MediaWiki and many different combinations of extensions, each with their own versions; and the more extensions there are, the more work it is for admins and the more things that can go wrong - and by extension, the more work it is for developers who have to document all the installation steps, detail all the version compatibility issues, and help with debugging every time something goes wrong. But, back to this specific issue: what exactly is the liability of having this PS SMW class/file contained in SMW? You and James have both said that it would cause problems, but I don't see how. Even in the worst case, where the code in the class is awful and doesn't work at all, as long as it doesn't affect the normal running of SMW it shouldn't be an issue for SMW developers. If you see a bug report or email relating to the SMW PS code not working, you can either ignore it or assign it to whoever is maintaining Page Schemas (at the moment, sending it to either me or Yury would be fine). Is it really an issue that one or more classes in SMW are not covered by unit tests, other than an aesthetic one? -Yaron On Sat, Aug 10, 2013 at 2:25 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, I can think of a number of things that SMW does, unrelated to its core goals: SMW core could indeed be more lean. 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). Diff is not related to SMW in any way. DataValues is based on SMW code though not yet used directly by SMW. That is something planned though. 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 is important to differentiate between the developer and the user views on this. From a development perspective it makes a lot of sense to have these things nicely kept separate. From a user perspective certain combinations of packages tend to be desired. This is why software tends to have a build process, so the selection of functionality needed by the user can be put into an easy to use bundle that appears to be one piece of software to the user. And since different users have different needs, you'd typically have a few variants of this. For instance SMW core with just the core stuff, SMW plus forms and related stuff, and ALL of the SMW things. Right now we are not doing an as good job at providing such things as we could. SB is a step in the right direction, though still far from what we could have. From a dev perspective it is important to keep district things separate, to avoid not needed dependencies creeping in, and to reduce maintenance costs. Since we have not all that much manpower for maintenance, we should be very careful about this. Some factors that are relevant in determining if something should go into SMW core are size and code quality. In case of the Admin Links hook, which is just a few lines of simple code, there is not all that much reason to move it out. There is more PS code though, and it is more complex. Plus it has design issues which combined with the lack of tests make it a liability. In the case of the PS code, I'm not convinced that having a PSSMW extension would be to much of an issue even without improving our current build and publishing process. After all, there are many much smaller MW extensions out there. 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.
Re: [SMW-devel] RFC: SMWPageSchemas in SMW core (1.9)
Hey, I can think of a number of things that SMW does, unrelated to its core goals: SMW core could indeed be more lean. 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). Diff is not related to SMW in any way. DataValues is based on SMW code though not yet used directly by SMW. That is something planned though. 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 is important to differentiate between the developer and the user views on this. From a development perspective it makes a lot of sense to have these things nicely kept separate. From a user perspective certain combinations of packages tend to be desired. This is why software tends to have a build process, so the selection of functionality needed by the user can be put into an easy to use bundle that appears to be one piece of software to the user. And since different users have different needs, you'd typically have a few variants of this. For instance SMW core with just the core stuff, SMW plus forms and related stuff, and ALL of the SMW things. Right now we are not doing an as good job at providing such things as we could. SB is a step in the right direction, though still far from what we could have. From a dev perspective it is important to keep district things separate, to avoid not needed dependencies creeping in, and to reduce maintenance costs. Since we have not all that much manpower for maintenance, we should be very careful about this. Some factors that are relevant in determining if something should go into SMW core are size and code quality. In case of the Admin Links hook, which is just a few lines of simple code, there is not all that much reason to move it out. There is more PS code though, and it is more complex. Plus it has design issues which combined with the lack of tests make it a liability. In the case of the PS code, I'm not convinced that having a PSSMW extension would be to much of an issue even without improving our current build and publishing process. After all, there are many much smaller MW extensions out there. 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)
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
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] 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
