By peterx on

We already have people talking about Web 3.0 even though nobody knows what is in Web 2.0. Why not talk about Drupal a way out into the future. Drupal 5 is on the way and I notice people taking about Drupal 6. That means people are already thinking about stuff for Drupal 6 that will be deferred until Drupal 7 because it is too big a leap. That leaves Drupal 8 for the really new ideas that do not fit anywhere else.

My suggestion is an XML transformation engine to work with the PHP template system. The idea struck me once before after a double shot undecaffeinated Columbian brew with fresh cow cholesterol. I wrote an XSLT transformation inside PHP template. The result worked but was not generic enough to solve the major problems of the world.

Now a year later, after a double shot decaffeinated Columbian brew with soy milk, I am revisiting the idea after revisiting Nvu. Nvu is the stand alone Web page composition component of the Mozilla tribe. You can use it along side Firefox and Thunderbird. You can use it to visually create your Web site layout and example pages then manually convert the results to a Drupal theme. Most beginner Web site owners learn the visual composition part but not the Drupal theme conversion.

What if we built an XSLT transformation to use instead or after PHP template? You use Nvu to create your same page with sample content. Everything is XMLised. You save the result as an XML page with elements named to rules similar to the Drupal block names and CSS class/id names. The XSLT transformation assembles the page into XHTML substituting the content from Drupal.

Elements would have three status:

  • Do not replace
  • Replace only if there is valid content
  • Replace with valid content or remove element

The XSLT transformation would need changing only if you add a module. Modules could contribute sections to the transformation and the transformation engine would assemble the XSLT from the modules. You could have a Drupal function drupal_module_interrogate::give_me_your_xslt. (Did I mention OO code for Drupal 8?) You add the XSLT from modules to the base XSLT and transform your XML template, which is just an XHTML page from Nvu or equivalent, and zap out a cool looking web page.

The object is to let people produce themes for Drupal without having to use code snippets or any of the junk you have to use for Dreamweaver, Coldfusion and all those other products. Think of six million Frontpage users switching to Nvu and generating themes for Drupal.

Comments

styro’s picture

styro commented

...you could just use Cocoon (or Lenya, Daisy etc on top of Cocoon) to sate your masochistic XSLT tendencies today. It would also get you bonus masochistic points for dealing with Java as well :)

Seriously though trolling aside, unless your content is external and natively in some richer XML based format I don't see any advantage with XSLT transforms. And I'm saying that as someone who will in the near future need to work out how to integrate native XML content (DITA) into Drupal.

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

peterx’s picture

peterx commented

Popoon is the PHP equivalent to Cocoon. Popoon gives you all the pain and complexity of Java without all the pain or complexity.
http://www.popoon.org/

petermoulding.com/web_architect

petermoulding.com/web_architect

samitchell’s picture

samitchell commented

Sorry in advance if this is in the wrong place or off subject.

I've been going thru the documentation and looking in the forums and this issue of integrating DITA content in Drupal has come up several times. But I haven't found anything so far that says someone did it.

Anton, did you get your DITA content integrated with Drupal? and if so, can you outline what you used to do this?

Thanks

styro’s picture

styro commented

Anton, did you get your DITA content integrated with Drupal? and if so, can you outline what you used to do this?

No, I never got around to it. Basically we ended up (not deliberately) whittling down all our documentation outputs to the point where we no longer needed single source publishing and just either wrote it in Drupal or direct to PDF with no real overlap in the actual content.

I would still like to have a single source publishing setup (and DITA is still the best for that IMO), but I don't have any spare time to set it up and for the moment don't feel like retraining staff (incl my boss) to have the discipline to be able write presentation free content :)

--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal

dman’s picture

dman commented

I've already done a quite workable on-the-fly XSLT engine as a Drupal module.
I've had it working as either a standard Drupal filter or an XML page type.
BUT, keeping my core data in an XML format wasn't really that much of a win for me.

... until I figured that microformats was the way to go.
Now my content is semantically tagged XHTML, which may optionally be processed incredibly via some magic XSL, but equally may just stand alone and remain accessable.

Previous discussions on XMLNode

I think referring to XSL as an answer for 'Drupal 8' is mad. XSL is a small, powerful but complicated beast, and I don NOT think that it's a substitute for PHPTemplate in any way. It COULD however be another of the template engines ... but why bother? Really?

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards

peterx’s picture

peterx commented

I am thinking about XML for templates, not content. My last XML module provided XSLT conversion of the output from PHPtemplate. There was no facility for directing output through multiple templates in sequence so I added a call to my module from within PHPtemplate at the very last line of PHPtemplate.

Gradually I added stuff to my XML module from other modules so that other modules could contribute data or XSL for the XSLT. The output is guaranteed to be valid XHTML. The output contained an equivalent of Drupal blocks. I stopped short of implementing Drupal blocks in XML because I was working in 4.6 and blocks were changing in 4.7.

If I did the work again, I would start with a template that could be generated in simple HTML editors including Nvu. My only requirement would be that they product valid XML when set to XHTML. I have not yet found an XML or XHTML setting in Nvu.

The template would be a standard Web page as generated by Nvu and other editors. All the user would do is set the output to XML or XHTML then add class names and ids to a set format. The XSLT would use the class names and ids to replace the template elements or data with the actual element or data. You could define something like <footer /> and get a Drupal generated footer or you could define your own footer that includes elements such as <div id="footer">your default content</div> and have Drupal replace the content with anything defined by the administrator.

petermoulding.com/web_architect

petermoulding.com/web_architect

rcross’s picture

rcross commented

I really like the idea of looking past just the next step, but the existing posts seem to be just commenting on your idea, so I'll throw out something else. Drupal 8 - hmm, alot of my issues lately have been starting to get attention (like the web installer, install profiles, new default theme, cck & views, and I imagine these will mature quickly in the next updates).
- Probably might happen before Drupal 8, but i would like to see some major changes in the user interfaces. Supposedly the UI has been analyzed by a professional "usability expert" and has been on the list for quite awhile and some things have definitely improved with the ajax stuff and some of the changes with 5.0, but i feel like these are incremental changes. I think a complete reworking of the ui might shake things up a bit (in a good way).
- I'm sure this is also starting to be incorporated as well, but with "web 3.0" around the corner I would like to see drupal 8 start including semantic markup in its output.
- From there (and since we're thinking out there), it would also be really interesting to see some AI (artificial intelligence) incorporated into drupal. A small example of this might be the bayesian inference in the spam module (currently exists). Maybe some other ideas might be including a neural network for learning spam. Or along with the UI idea, maybe a learning algorithm that can adjust the UI based on a users past usage or detecting what task the user is trying to do and then stream lining that process to suit them on the fly. Maybe taking the RSS aggregator a step farther and doing some data mining or something to do some automatic (intelligent) content generation.
-I"m sure i could keep day dreaming, but i'll stop before i jump off the deep end =)

--Ryan

--Ryan
Ryan Cross
James Cross Construction Services
Project Management Software

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Here are some things I'd like to see and hopefully work on some in terms of core in the future:

  • Integration of Adrian's "API API" ... storing basically everything as structured arrays to allow programmatic alteration of pretty darn much anything.
  • Robust relationships API... user -> user, user -> node, node -> term, user -> term, etc. Could replace a ton of modules out there.
  • Views-like page/block query building framework in core.
  • Fine-grained permission system; give users the right to update nodes categorized by certain terms, or the right to update terms in a certain vocabulary, or add other users to roles within a defined set, etc.
  • "Outline" module to handle grouping collections of nodes together (could be used to create more robust book and forum module).
  • Rewrite of aggregator module to use taxonomy and save results as nodes.
  • Pofiles as nodes, using CCK field generating code. That probably also means integrating some base field types (text, number, date, etc.) into core.
  • Validation API; including some basic validation behaviours that can be attached to node fields and then extended by other modules.
  • A more robust file API that can handle saving files to different directories, storing a user->file relation, encryption, both public and private files at the same time, etc.
  • Ditch as many modules from core as possible; ideally, core is just a small few modules like block, filter, menu, node, menu, system, etc. and the rest can be supplied in contrib and enabled with install profiles.
  • More robust image, media, etc. handling in core.
  • Integration of Actions/Workflow functionality into core.
peterx’s picture

peterx commented

I like the idea of doing something with the user. I would like the use profile easily extendible by users so that the Drupal user could be used by CiviCRM and other modules as their user record. Using CiviCRM as an example, you could send all your people, the contributors and everyone else, a login to your Drupal site so they can maintain their own profile. When they login to your site, they would update one profile which would be used by both Drupal and CiviCRM.

The next extension would be to have something equivalent to the "new" feature in Drupal forums but for mailouts. CiviMail and similar modules could send mail through a Drupal mail archiver that would list information similar to the Drupal recent posts page. The user could receive a short email with the summary text, the teaser, and visit the full pages through links. If they do not click through all the links on the email, the "recent items" page would show all the unread stuff marked "new".

CiviCRM, XRMS and other products could plug into the architecture and make full use of the Drupal user facilities without having to maintain their own tables.

For an example of extensibility that is already in CiviCRM, look at their facility to add extra user defined fields. If that was already in Drupal for the user information, you could customise your user records on your site and every module could read the extra fields you add. They would not be limited to one module.

The next step would be to have user groups something like CiviCRM's organisation. You could take the CiviCRM organisation out and make it a separate optional module that could be used in Drupal without using all of CiviCRM. You could then use it in e-commerce so that a customer can register a company and list all the staff from that company that can buy for that company. The organisation can then manage their own users without worrying the Web site administrator.

petermoulding.com/web_architect

petermoulding.com/web_architect