创建网络社区

Thanks for taking the time to read and reply to my posts.

That's a good question, and one that I've wrestled with a bit. As you can probably tell from what follows, I have some doubts about whether there really needs to be a language for this. In the end I've convinced myself that it's worthwhile to at least experiment with this.

This looks interesting. But I'm not sure that we need to be a new language. The Drupal way seems to be to define things using arrays.

There are a couple of motivations for going to a 'little language', rather than sticking to the existing CCK representation. I wanted a representation that was

1. a little more language/platform agnostic.
2. higher level, to eliminate 'minor details'
3. suitable for use as a modeling language, or intermediary for UML.
4. easy for humans to read, edit, and version

Basically, 'easier for humans, still easy for machines' is what I'm aiming for. Eventually (soon?) I'm hoping to be able to model my types with a UML tool, convert to CoCKTaiL, and then have the CCK import-ready PHP code generated.

Are you proposing a new utility that is totally separate from Drupal, simply for inporting and exporting CCK types?

There's lots of places this could go. At the moment, I'm working on a couple of stand alone utilities. Clearly it would be easy to incorporate the parser into a module to accept CoCKTaiL for import rather than the CCK php code.

But perhaps the most interesting application would be 'Enterprise integration' - a way for organizations with heterogeneous, complex systems to start to see Drupal as a component for cost-effective, rapidly deployable solutions to integrate with or replace existing systems.

I'd like to see a Drupal module, with an import/export feature, where the definitions could be pasted into php. This would lend itself more to an array syntax rather than a language definition.

Right! Import from CoCKTaiL should be easy. Export to CoCKTaiL, I'll need to look, but it doesn't seem too difficult.

I've done a lot of language work in the past and I understand parsers. But we have gotten pretty far in Drupal without them. I even avoided it in coder, opting instead for lots of regex checks.

PHP has the cool feature of having its tokenizer available, which provides a lot of muscle to certain applications. But the (surprising, to me) truth is that for PHP there haven't been good parser tools available until fairly recently . Maybe people didn't take it seriously? To me, it now looks like it's pretty much becoming what C++ was hoping to be. I expect we'll see more good tools for PHP.

Another aspect is that a lot of people have abandoned writing parsers (which can be a pain) in favour of using XML and transformations. This is great as long as humans don't have to read or understand the language :)

So, I'm wondering why you think that the CCK definition needs to be a language. It feels very un-Drupalish.

I think that the present CCK representation is great - as an internal, or even Drupal to Drupal representation. It's direct, does the job, and is close to the objects it's representing. I'm writing CoCKTaiL as an experiment in representation in what might be thought of as a 'modeling and messaging' layer, which is by definition outside of Drupal. So, hopefully it is not inappropriate that CoCKTaiL be somewhat un-Drupalish, as it's kind of an adaptor, if you will.

I just made that up :) I hope it's not too hand-wavey.

Thanks!

BTW, I've started with a bunch of code metrics and static analysis work, too. I'd love to chat with you about coder module and your thoughts for future directions.

Cheers, Djun