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=48897031&iu=/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=48897031&iu=/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. 
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

Reply via email to