Obliterate about() methods in data sources and events? #1356

Closed
nickdunn opened this Issue Jun 6, 2012 · 9 comments

Projects

None yet

6 participants

Contributor
nickdunn commented Jun 6, 2012

We've killed the about() method in extensions in favour of the extension.meta.xml file. Yay for data portability!

Got me thinking (http://symphony-cms.com/discuss/thread/35546/3/#position-48), do we really need these files in data sources and events? Is it useful to know the developer (name, email and website) that created the data source? Is it useful to know the Symphony version number that was used to create it? Is it useful to know the creation date, to the second?

My gut tells me none of this is useful. If you're developing on your own, you know you created it. If you're developing as a team, you're using source control which is far more useful. When extensions are bundled with extensions this stuff is more useful since it adds context when the data sources are shown amongst the other data sources on a site. But for day to day, I find this meta data useless.

My suggestion would be to kill everything in the about() array except name and perhaps author name. If they are provided by extensions then this related metadata should be pulled into the Symphony UI at runtime, rather than being hard coded into the data source file itself (i.e. a custom Search Index data source shouldn't need to have my name embedded in it, since this can be gleaned from the extension that exposes the file).

Also... data sources created by the core use the version key for the Symphony version, but custom extensions provided by extensions use this to reflect the extension version number (which is usually out of date because developers forget to update it). Confusing?

Owner

I always find it irritating to see my local development environment url in the meta for a datasource/event after the site is live. I would prefer to see more documentation and datasource/event output examples in the datasource/event, especially for customised ones.

I feel some advances on the extension meta schema coming on... I am primed!

Owner

which is usually out of date because developers forget to update it

Every time for me.

If you want to get the name of a DS/Event, let PHP's Reflection do the work. The author can always come be in a comment (this is reflectable too btw).

+1 for removing about() metadata from datasources and events too.

Member

+1

I always find it irritating to see my local development environment

Same here.

Owner
brendo commented Jun 7, 2012

We can definitely clean it up a little.

  • Version was supposed to allow extensions (and the core if need be) migrate datasources between extension or Symphony updates. This parameter is updated everytime a datasource is saved so it should be accurate. Obviously if it's a custom datasource then this does not apply.
  • Release date can be removed, I can't think of a situation where this can help, for extensions this is derived by the extension release date and for normal /workspace datasources I don't know why this would be important.
  • The Author URL is definitely useless, but I have found the Author Name/Author Email useful to badger a developer in the office (or an extension developer) when I have a question about what they have done (not all projects have source control).
  • There is a description key that Symphony reads when a datasource is not allowed to be viewed in the backend, although I bet the majority of Symphonians have no idea this even exists ;)
  • While you can use Reflection to read docblock comments, it'd always be faster to just read the data directly of the datasource. It would be an interesting avenue to explore though, as it would be like commenting a normal class and is more flexible. There'd be no issue in writing this data as datasources are just based of a plain text template anyway.

How do we want to approach this? Obviously this would be a 2.4 change (as in complete removal, we can remove useless settings now!), as that gives us a clear deprecation period (and time to decide on the best result). With 2.4 being PHP5.3+ only, I think exploring the use of Reflection would be interesting (we've found that Reflection is a bit unstable on PHP5.2 while investigating some other core ideas)

Contributor
nickdunn commented Jun 7, 2012

If the about array is the best place to store the needed stuff then so be it, let's just cut the cruft out. No need to make this harder than it needs to be.

Why not just kill everything other than name and author name/email, and allow the latter to be optional?

  • description: had no idea this existed, do any DSs ever use this?
  • version: does it have any practical value?

If a DS/event is provided by an extension then I think the metadata shown in the backend table should take pertinent info from the extension meta file (extension name, version and author?).

Owner
brendo commented Jun 7, 2012

description: had no idea this existed, do any DSs ever use this?

I haven't seen any in the wild use it, but we use it often to describe custom data sources at work.

version: does it have any practical value?

Other than acting as reference for migrations, no.

If a DS/event is provided by an extension then I think the metadata shown in the backend table should take pertinent info from the extension meta file (extension name, version and author?).

Unless the extension provides multiple datasources, in which case it'd be more useful to document it at the datasource level. There's ways around this though, Members makes use of the Datasource->documentation() function, another hidden gem I suspect ;)

Contributor

description: had no idea this existed, do any DSs ever use this?

Yeah, I used it :)

Owner
brendo commented May 6, 2013

Nothing to gain with this in Symphony 2, consider it conceptually for Next.

@brendo brendo closed this May 6, 2013
@brendo brendo referenced this issue in symphonycms/symphony-next May 6, 2013
Open

Things it should have #1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment