Symphony.

So, building on what I’ve created for the System Navigation ensemble and the Address Book ensemble, I have built the basic framework for the Projects ensemble. This is not a fully functional ensemble, so be warned. In fact, there is bug that needs to be resolved for the list view of the /projects/items/ directory to allow the page to render (even though the subpages are working). Unfortunately, the debug page is less than descriptive in this case.

In addition to the debugging, I have some section link menus to hook up. But I just thought I should mention that this ensemble seems to have solved the problem of multiple section links in a single section.

Multiple Section Links in a Single Section

While the functionality is not available in the Symphony admin, it appears that multiple section links will work quite well on the front end. The key is to use IDs for the select option value attributes and to assign an appropriate title value to the select option text values.

I’ll be exploring this possibility further, but in the meantime, you can view the select fields that do work on the /projects/timesheet/ page.

I could do this the easy way, by hard-coding XPath expressions, but I’m trying to make the templates as easily configurable and reusable as possible. So, for the most part, the templates are driven by parameter values that all point back to initial configuration values.

The concept is built on the idea of an XML/XPath family tree:

• ancestor
• parent
• self
• child
• descendant

At first, I thought I would build only with the ancestor, parent and self nodes, since I was working with three columns for overview pages. That way I could build triads of entry relationships:

• Navigation: menus/sections/pages
• Contacts: types/organizations/people
• Projects: projects/items/timesheets

However, I new that I had to relate projects to clients. So I will be adjusting the templates to work according to a multi-level hierarchy. For now I’ll keep it to five, so that I need only manage parameters for the five levels described above.

First, I was thinking that, depending on where you are in the hierarchy, the overview template would have the following URL parameters:

• ancestor/parent/self
• parent/self/child
• self/child/descendant

Now, I’m thinking that a three column overview should always have the same set of relationships in view:

• parent/self/child

That way, the entire page can reference pages above and below itself in the hierarchy by referring to ancestor and descendant.

The other option would be to refer to each level in a less verbose manner:

• a/b/c/d/e

However, a search-and-replace is much easier for terms like ancestor, parent, self, child and descendant. And XPath and XML tend to be more human readable formats, so I think I will keep to the native XPath terminology, as it may enhance the ability to understand the concepts.

Here is the Projects ensemble so far, for what it's worth.

Here is the latest build. The list views are not counting section link children properly, but I think that most everything else works okay.

Included is multiple entry editing and multiple section links. Ultimately, though, the multiple section links feature is flawed and will definitely suffer from scalability problems when lists become longer. Also, changing the parent section link relationship will not change the relationships for child entries, so that would be an entirely manual process. What does work is that changing the name of a section link will be updated dynamically for all child entries.

The ultimate goal is to add additional URL parameters to provide context for the lists and employ data source filtering to limit the lists to the current context.

Fixed up the counting for section link children and fixed up a few other bugs. Next is context filtering, which will require modifying the URL parameter structures.

Projects Ensemble 0.2

Updated the ensemble from Symphony 2 Beta Revision 5 to Symphony 2.0 (zip download). It also includes a brief introduction to Symphony that provides a quick tour of the system.

Edit: for whatever reason, the ensemble did not save all the utilities. Replace the workspace directory with the complete workspace, attached below.

hey bauhouse, i was trying to use your ensemble, but i'm getting this file as missing:

public-master.xsl

Also, when i downloaded the latest version, only the calendar.xsl file was in the utilities folder. I tried piecemealing the different versions together, and when I did that, I got this error:

navigation.xsl line 8 element choose
XSLTProcessor::transformToXml(): Variable 'page-type' has not been declared.

any clue?

Projects 0.2.1 workspace

This ensemble replaces the corrupt version I uploaded previously (missing utilities in the zip archive). That's what I get for not testing. (I couldn't upload the full ensemble because the forum limits upload size to 500kb.

bauhouse - I've been playing around with this ensemble and it has a good architecture in terms of keeping projects grouped together. I'm not sure if it's just my server (very well could be, i'm on dreamhost) or if it's the ensemble that's slow in rendering each page when I click into each individual project and its items/time entries.

My main purpose of trying this ensemble out is to mainly keep track of time entries for each project. However, with the current set up, its hard to just add hours to each item since you have to create/copy a new time entry versus just seeing a set of hours on the same page. Not sure if this post makes much sense since I'm a little distracted by guests, but what do you think a possible solution could be to displaying all the hours on one single page per each project item?

I think what you are noticing is the reason for what was almost the abandonment of what has now become Symphony 2.0: performance issues. The bottlenecks have been documented and a solution proposed. The solution has become such a large project that it is now referred to as Symphony 3.0.

So, ultimately, Symphony 3.0 is the solution. Until then, a custom extension that is able to get around the performance issues by interacting directly with the database, would be the next best solution. Failing that, it would be possible to create page templates that list time entries by client, by project and by project item and hope for the best as far as performance goes.

At the moment, I'm experimenting with developing extensions to see how far I can get with a custom extension. Which is why I haven't spent time trying to finish the Projects ensemble and complete the feature set I've had in mind for it. If more people are seriously interested in using the Projects ensemble, I'd be more inclined to at least develop the rest of the interfaces, and we can experiment with which would be the best solution as far as back end architecture goes.