Skip to content

Symphony 2.3 scope meeting

Jump to bottom
nilshoerrmann edited this page Jul 21, 2011 · 12 revisions

Symphony 2.3 scoping meeting

Purpose

To define a scope for the Symphony 2.3 release (Nov 2011), based off the current issue tracker (summarised below) and then bespoke feature requests (some listed below, others may be brought up in the meeting). Some of these items have been discussed before, others have not. Now is a good time to briefly discuss these and decide if it'll be in Symphony 2.3, or if it will feature in a future release (yeah, we're trying to be a little more forward thinking), or not at all.

Who's invited

All members of the Symphony Working Groups are encouraged to attend (we can attempt to have the world's biggest virtual man-hug if that's your sort of thing), general users can also participate but this is not a place to vent troubleshooting issues (our lively forum is for that sort of thing)

After the meeting

After this meeting we should have a clear scope of Symphony 2.3 and a rough idea of who is taking ownership of what.

Discussion points

The Realign effort

This currently lives in Nils' repo. We are currently moving the designs to the realign branch of the main repository.

Need to flesh out what this includes exactly, it's the sort of thing that can go on for months to nail, we need to be realistic and focus on the top things that will make the biggest difference right now. The rest can come later.

  • Are we going to change any of the Editors? That is, Section, Datasource or Event. [Section: UI update, Datasource: rewrite, Event: as is]
  • Are we going to remove the Components page and replace it with something (but probably not exactly) like EDUI? [Yes, no pagination]
  • Is it worth looking at how Symphony works on mobile devices? Is this something that should be core or extension? [Not in scope, 2.4]
  • Is it worth looking at displaying the Extensions page any differently? [Yes, type, README viewing]
  • Symphony currently adds JS in the head, which is bad practice, are we going to attempt to rectify this? One option is just mapping addScriptToHead to a addScriptToFooter function which does this automatically. Are there any problems in doing something like this? [Yes]
  • Minification, and all that goes with it, can wait for 2.3.x I feel. [If there is time, 2.3, otherwise 2.3.x, combine the Symphony core plugins]
  • Create Notify, Tab, Drawer plugins
  • Create Widget::* representations of the plugins to make writing the markup quicker!
  • UI Filtering, can something like Publish Filtering be implemented everywhere? [If there is time 2.3, otherwise 2.3.x/2.4]
  • With Selected and Alert messages
  • How do we know when we are done? Interfaces are always iterative, but there needs to be a point where we stop, release and go again.

(Note by @nilshoerrmann: This were our notes a few months ago: https://gist.github.com/1004279)

Datasource Filtering

Mentioned above, but there is a couple of issues relating to how we can make this more intuitive. #699 and #712

There's also proposed changes to the Dynamic datasources:

  • Rename to Remote XML/JSON
  • Allow clearing of the cache times from the Datasource
  • See how long a cache is left
  • Automatically detect namespaces (XMLImporter has example code to do this)
  • Ability to 'ping' the URL to determine it is correct

[Win to all]

extension.meta.xml

Yay or nay? The idea is to replace the about() function of extension.driver.php with an XML file that will also include the compatibility and types array. While it's unreasonable to expect that all developers will update their extensions for 2.3, the longer we wait before making a decision, the greater the number of extensions this will affect. A transition period will be needed regardless.

[Yes, support about() for 2.3/2.4, allow newer compatibility only in the XML]

JSON as a first class citizen

There is two facets to this, JSON datasources and JSON page types.

  • JSON Datasources, aka Remote JSON Datasource, has been started in this branch. Currently it uses the majority of the Dynamic XML code, including using XPath for selecting. Is there a JSON alternative? It feels a little clunky using XPath on something that is 'JSON'. Not that big a deal though I don't think?

[Win, possibly combine JSON/XML and use content negotiation]

  • JSON Page types, 2.3 or later? This would be the opposite of the datasource where we transform JSON to XML, rather it will be XML to JSON. There is an IBM standard to do this which we should be able to use. Do we want users to create JSON Page's in XML and have it transformed by Symphony to JSON? Or can we just make the user write JSON? I feel this can wait for a 2.3.x release.

[Waiting for 2.4 to discuss again, use Content Type Mappings extension in the meantime]

Better configuration

In Symphony 3, an interface exists for editing the config.php file. What do we think about bringing this to the Symphony 2 branch? Existing discussion #703 Could potentially arrive in a 2.3.x release rather than 2.3, but may be useful to know earlier in terms of the Realign effort

[No, extension exists, lets use that]

Core fields as extensions

Symphony 3 has done this, it simplifies the managers because they only have to look in one place. Not sure what other benefits this would bring to the table though, may be wasted effort in 2.3 and could wait for a later release IMO

(Note by @nilshoerrmann: This needs to be discussed with the installer in mind. If the core didn't bundle fields directly any longer, it would be possible simplify the install class and have all fields installed via the install functions of the respective extensions. Furthermore field updates could be handled independently.)

[No, 2.4 or beyond, lacking tangible benefits, we have cooler things to do]

Field combinations

There's been talk about the core fields should do more, Upload Field is a commonly cited example, what do we want to do here? Is there any that are absolutely critical?

(Note by @eKoeS: This old writeboard can probably serve as a source of inspiration)

[Needs more discussion, lots of opinions and ideas, but want to avoid cluttering the field settings with lots of options. Input/Textarea (wrt to Number, Text Formatters, Uniqueness) and Upload (Uniqueness) are two common gripes]

Various Email API bits and pieces

Probably doesn't need discussion, Michael and Huib are the guru's here. Related Issues

[didn't discuss, Huib briefly mentioned there is some work involved but he's up for it]

XMLImporter/Import/Export

There is an old Field function, canImport. I have no idea of the origins, but perhaps we could 'yell' about this and make it standard for these extensions to use this? XMLImporter also will use a function prepareImportValue which is similar to processRawFieldData. How do we feel about making this a standard function that fields implemented? The default would just map to processRawFieldData. prepareImportValue could also have a partner, prepareExportValue that maps to getParameterPoolValue

[investigate why these functions are needed instead of the standard ones anyway?]

Housekeeping

This is the list of issues on the tracker to discuss, did we nail all of them?

(Note by @nilshoerrmann: There are a few open issues left on the issue tracker on the Symphony site that have not been ported yet.)

[didn't get time to discuss]

Other

  • A beta around October 3 (after Symposium)
  • An RC mid November for launch before December gets messy.
  • THANKS TO ALL WHO ATTENDED AND CONTRIBUTED!
Clone this wiki locally