Yaml

[vgarcia]

@vgarcia: Not sure I'd completely agree that XML itself is slower than any other format. But significantly better engineered, say for I know XML can handle utf-8 data, but parse_ini ? How knows..

Let's take the world's simplest configuration, in 2 formats.

XML:

<?xml version='1.0' encoding='utf-8'?>
<config>
<enabled>true</enabled>
</config>

A properties file (similar to an INI file, used a lot in Java apps):

enabled=true

Which would cause more overhead in parsing?

XML's not without use; I just think simple application config isn't the best use for it. If you find that you need to represent complex structures in your app config that ini files or yaml or whatever can't provide, then by all means use XML, but odds are if your app config is that complex it can be simplified.

[McGruff]

If the aim is to "allow non-PHPers to create simple applications" can you assume that they'll be comfortable with XML or anything mentioned so far (apart from simple word processing...)? Maybe you could explain a bit more how the final app will be used.

I wouldn't begin by thinking about machine-readability. As long as the information is in there somewhere you can dig it out. I'd start with the simplest possible way you can think of for the user to specify what they want.

[crashmakerMX]

Crash, I don't see why format matters. If, as you say, you are targeting non-programmers, then you'll want to give a friendly user interface to things, including editing configs.

1. The belittlement of my nickname is Crashie

2. Not necessarily. For non-PHPers it's also easier to write YAML

[Ren]

Let's take the world's simplest configuration, in 2 formats.

XML:

<?xml version='1.0' encoding='utf-8'?>
<config>
<enabled>true</enabled>
</config>

A properties file (similar to an INI file, used a lot in Java apps):

enabled=true

Which would cause more overhead in parsing?

XML's not without use; I just think simple application config isn't the best use for it. If you find that you need to represent complex structures in your app config that ini files or yaml or whatever can't provide, then by all means use XML, but odds are if your app config is that complex it can be simplified.

It should be negilible difference, and both formats do not offer the same amount of flexibility anyways.

[crashmakerMX]

If the aim is to "allow non-PHPers to create simple applications" can you assume that they'll be comfortable with XML or anything mentioned so far (apart from simple word processing...)? Maybe you could explain a bit more how the final app will be used.

Well, Phanteon is a framework for simple developing and to make it simple even for non-PHPers I would like to allow them to describe the application in an easily readable (for them) format. This format is just another layer of abstraction, you can of course use PHP and that is preferred.

[BerislavLopac]

The biggest problem with XML for configuration imo is how tedious it is to write.

I would agree with you if there wasn't so many useful XML tools around.

[Selkirk]

There's SDL, too.

[The New Guy]

Well, Phanteon is a framework for simple developing and to make it simple even for non-PHPers I would like to allow them to describe the application in an easily readable (for them) format. This format is just another layer of abstraction, you can of course use PHP and that is preferred.

Might want to consider a GUI app rather then a bunch of config files.

[kyberfabrikken]

Which would cause more overhead in parsing?

C'mon. If clockcycles are that important to you, you wouldn't write your application in an interpreted language.
Anyway, XML-parsers are provided as binary code in both versions of PHP. For YAML, he'll have to write his own interpreter (in PHP). I know where my bets are at.

Well, Phanteon is a framework for simple developing and to make it simple even for non-PHPers I would like to allow them to describe the application in an easily readable (for them) format. This format is just another layer of abstraction, you can of course use PHP and that is preferred.

If your audience is inexperienced programmers, I think XML is an excellent choice. Some of thoose will be people who have had experience with programming in other languages (Even if only HTML). Thoose will likely already know the syntax of XML, but might not know YAML.

[crashmakerMX]

If your audience is inexperienced programmers, I think XML is an excellent choice. Some of thoose will be people who have had experience with programming in other languages (Even if only HTML). Thoose will likely already know the syntax of XML, but might not know YAML.

Good point!

[dreamscape]

2. Not necessarily. For non-PHPers it's also easier to write YAML

easier to directly write YAML or some other file format than use a friendly user interface? That's a bit off the wall.

But really, I think if you have any intentions of seriously writing something to be used by regular people, you really might want to reconsider your stance that a friendly user interface is not the best and easiest way for people to interact with your product.

Otherwise it makes no sense to pursue. I mean you realize that you're essentially asking what the best computer language is for people who don't work with computer languages. That's beyond rationality.

If the aim is really the impression you are giving, then I agree with McGruff. You're asking the wrong question from the wrong direction.

[crashmakerMX]

Making the development part of the application (there's also a WCMS part) usable to non-programmers is just an idea and would be only a minor feature among a bunch of others.

YAML, XML and the like are not programming but markup languages, which makes them more suitable for non-programmers.

Conclusion: I'll use plain PHP for configuration and if I add this special feature I am going to use XML.

[jayboots]

It would be nice if folks actually posted criticism or ideas regarding YAML instead of trying to continually sell XML in this thread. Probably the worst thing about XML is that it has become everyone's favourite hammer. Sure, it is a great technology but it is definately not suited for EVERY task. Having done a lot of text processing work in my career I've come to really think-twice about my initial early adoption and exhuberance over XML. It is NOT a very friendly format in many ways. So the only thing I'm asking here is: please don't shout down other formats just because you think XML is all that.

[kyberfabrikken]

jayboots, I agree that XML has been completely overhyped, but I have the feeling that this has resulted in a counter-movement, where people theese days will pick anything other than XML for exactly the same reasons that they would have picked it up in the past. I'm not saying that is what you or anybody else in this thread are advocating, and there certainly are problems with XML, but it does carry a lot of weight that it's such a well-established standard.

[dreamscape]

jay, it's been difficult to post ideas about anything since I don't even think the OP knows really what he's wanting to do; or at least it seems to me he keeps changing his stance on what he's trying to accomplish with every post he makes, which is ok since he's just planning I gather, but it makes it difficult to give advise on the issue when the issue keeps rapidly changing.

BTW, I did post constructive criticism of YAML, clear back at the beginning as I recall saying that it is likely used as much as it is in Ruby because Syck has been a core part of Ruby since almost its [Syck's] beginning. But PHP has no built in support, so really there are probably formats that in reality are equally easy to use but which PHP does have core support for.

[jayboots]

Hi. Actually, I didn't mean to suggest that XML is useless or that it should be avoided -- far from it! Still, here we finally have a thread where someone asks, "hey, what about YAML" and the bulk of the discussion seems to center on either "use ini format" (which is a mis-start because the capabilities of ini format are miniscule compared to YAML) or "only XML matters" (with the underlying notion that XML is always the best choice and that anything else is "unprofesional"--pshaw).

As for Syck, it was released for PHP at the same time it was released for (at least) Python and Ruby. _why happen's to be a Rubyist and the Ruby community (wisely) embraced the work that the YAML folks were doing -- so they quickly incorporated it into the base. _why offered to do the same for PHP (Syck was released with postings to the major dev mailing lists for each of the languages and as I recall with the offer to do the work needed to fold it into the cores) but the PHP group showed no interest. Indeed, nearly the entire PHP community seems to show no interest -- personally, I don't really understand why that is. Oh well, at least JSON has finally made it into PHP's (dev branch) core.

YAML is clean, expressive, can represent a variety of complex data structures in a straight-forward manner, is small (non-verbose) so it transfers well and supports interesting streaming (document), serialization and node related ideas (like internal links). I'm not suggesting YAML is the end all, but it nicely fills a niche between paltry ini files and overly complex (ie: over-engineered) XML files and does so in a simple and readily usable way.

That said, there are clearly cases where XML is a much better choice -- but I feel that it comes at the cost of additional complexity, size and sheer verbosity when compared to YAML.

EDIT: btw, I think XML is better suited than YAML at describing data while YAML wins at representing data. What I mean is that XML is probably better suited for storage while YAML is better suited for serialization.

[rossriley]

Well I'm going to stand up for YAML, and not because it's easier for newbies but because it's easier for me. I'd say there's a bit of snobbery here because it doesn't look like a proper programming language. Take an example:

site:
  name: example.com
db:
  adapter: mysql
  socket:  /usr/local/tmp/mysql.sock
  ....etc

That is poetry, data reduced to its most simplest and unobtrusive form.

Worried about the overhead? Just cache the resulting php array and only re-parse when you change the file. I want to know what serious programmer would argue that XML can do a better job of storing configurations like the above(note not data).

KISS (keep it simple stupid).

[BerislavLopac]

site:
  name: example.com
db:
  adapter: mysql
  socket:  /usr/local/tmp/mysql.sock
  ....etc

That is poetry, data reduced to its most simplest and unobtrusive form.

How is that different from this:

[site]
  name = example.com
[db]
  adapter = mysql
  socket =  /usr/local/tmp/mysql.sock

True, INI can't hold more than two levels, but if you need configuration with more than two levels you have other problems than parsing it.

[crashmakerMX]

jay, it's been difficult to post ideas about anything since I don't even think the OP knows really what he's wanting to do; or at least it seems to me he keeps changing his stance on what he's trying to accomplish with every post he makes, which is ok since he's just planning I gather, but it makes it difficult to give advise on the issue when the issue keeps rapidly changing.

Things I want:

1. to know if any of you have experiences (good or bad) with YAML and YAML in PHP (main point)
2. a configuration format
3. a description format for very simple apps (a guestbook for example). That's just an idea, nothing I'm going to implement neccesarily.

The first posts were on topic, but then it became a discussion about XML-hype and my idea about code generation.

[rossriley]

True, INI can't hold more than two levels, but if you need configuration with more than two levels you have other problems than parsing it.

This is the config from one of my applications, and is a good indication of why I prefer YAML to INI. To be fair, INI is not a bad format, I'd just choose YAML for extensibility.

development:
  db:
    dbtype: mysql
    host: localhost
    port: 3308

production:
  db:
    dbtype: mysql
    host: example.com
    port: 3306

Basically YAML can be as flexible as setting up your own array. My main argument was against the use of XML. If you subscribe to the do the simplest thing that works philosophy then you should choose INI or YAML. You should only choose INI if you're confident your needs won't expand.

XML on the other hand carries a huge amount of unnecessary baggage for the simple task of configuring an application.

crashmakerMX:
1. to know if any of you have experiences (good or bad) with YAML and YAML in PHP (main point)
2. a configuration format
3. a description format for very simple apps (a guestbook for example). That's just an idea, nothing I'm going to implement neccesarily.

Yes YAML with the Spyc class is excellent. Our in-house framework and many other community frameworks (as previously mentioned) use it successfully. Only proviso is that you should cache the configuration to avoid continual reparsing.

Configuration format: see above for an actual excerpt from our config file.

[crashmakerMX]

development:
  db:
    dbtype: mysql
    host: localhost
    port: 3308

production:
  db:
    dbtype: mysql
    host: example.com
    port: 3306

Looks like Rails... ;-)

XML on the other hand carries a huge amount of unnecessary baggage for the simple task of configuring an application.

Yes, that's also my argument against XML for configuration.

Yes YAML with the Spyc class is excellent. Our in-house framework and many other community frameworks (as previously mentioned) use it successfully. Only proviso is that you should cache the configuration to avoid continual reparsing.

That is something I wanted to know. Thanks :-)

I would cache it, of course.

[McGruff]

The first posts were on topic, but then it became a discussion about XML-hype and my idea about code generation.

Discussing your ideas is the cucial thing though. Unless I know exactly what you want to achieve I can't think how to do it. We've had a long discussion about xml etc which may have its own merits but quite possibly is completely irrelevant to the problem at hand. It's a classic, time-wasting pattern. You won't get away with that in a professional environment.

Now OK this isn't a professional environment and I'm not judging you but I think it's a point worth making. Lack of clarity gets you killed in programming. Once you've got the first, clear requirements everything follows on from there. I couldn't write a line of code any other way.

As a phpUnit user, I guess you're not much into mocks and TDD? I'd strongly recommend experimenting. This helps to drum in some good habits. Every step of the way you're coding against clearly defined requirements. The focus changes so much that I sometimes feel like I don't really write code any more: I write tests. The code almost seems to write itself - some light exercise after all the real work.

[crashmakerMX]

Discussing your ideas is the cucial thing though. Unless I know exactly what you want to achieve I can't think how to do it. We've had a long discussion about xml etc which may have its own merits but quite possibly is completely irrelevant to the problem at hand. It's a classic, time-wasting pattern. You won't get away with that in a professional environment.

Now OK this isn't a professional environment and I'm not judging you but I think it's a point worth making. Lack of clarity gets you killed in programming. Once you've got the first, clear requirements everything follows on from there. I couldn't write a line of code any other way.

Hey, that's not a new problem for me ;-). My project began over two years ago and changed names, programming habits and conceps like hats. It's a personal problem, I can't decide once and keep the decision. This time I'm doing a long phase of planning and trying out things before actually starting to develop.

As a phpUnit user, I guess you're not much into mocks and TDD? I'd strongly recommend experimenting. This helps to drum in some good habits. Every step of the way you're coding against clearly defined requirements. The focus changes so much that I sometimes feel like I don't really write code any more: I write tests. The code almost seems to write itself - some light exercise after all the real work.

I'm using PHPUnit 3 from CVS (Sebastian recently applied my patch) which supports mock objects. Why do you think someone couldn't to TDD with PHPUnit? Anyways, I've used SimpleTest several times (did I tell you about the decision problem? )

I've experienced this "flow" sometimes.

[McGruff]

I haven't used phpUnit but I'm sure the mocks work fine. However mocks weren't added until fairly recently and I don't know if there's much of a TDD culture amongst its users compared to SimpleTest (or in php as a whole for that matter - will the Zend framework suffer for that..?). Without mocks, you can write single classes, one at a time test-first. With mocks, testing can drive the whole application design. Each test throws up a bunch of interfaces (the mocks) for the next layer of objects.

[crashmakerMX]

I haven't used phpUnit but I'm sure the mocks work fine. However mocks weren't added until fairly recently and I don't know if there's much of a TDD culture amongst its users compared to SimpleTest (or in php as a whole for that matter - will the Zend framework suffer for that..?). Without mocks, you can write single classes, one at a time test-first. With mocks, testing can drive the whole application design. Each test throws up a bunch of interfaces (the mocks) for the next layer of objects.

There are still some quirks with the mocks but I fixed most issues

Interesting point. There are presentations about TDD with PHPUnit and a section in the manual about it. But the only place I see TDD in PHP is at this forum and the projects of its members.

Crashie