Packaging ;)

[448191]

Now that I'm finally looking into properly organizing my frameworks components I find myself struggling with dividing classes into packages.

Example:
Config_Xml - provides interface to configuration variables stored in an XML file.

Should I put that in a Config (allows for different storage methods like ini), or XML package (various classes that have a high level on dependancy on each other)?

My guts originally said to go with XML, then Config, now I'm back with XML, because of the dependancy issue. One should probably try to limit package dependancy when possible.

Another caveat:
Xml_Xhtml - used to manipulate Xhtml documents that will eventually be output. Part of the view package or XML?

Any thoughts?

[Jenk]

It should be part of your Config package. XML is merely a standard for data, where as your 'Config' is a package of Config items.

If you make, say a DataAccess object that uses XML, add that to your DataAccess package.

[448191]

Right. I went on and did so in my framework class diagram (dataObject) already. It was the "package dependancy" issue that had me doubting again.

How about Xhtml? View_Xml_Xhtml or DataObject_Xml_Xhtml?

Option 1 seems more natural, but option 2 more logical... :(

[Jenk]

XHTML should not in an object with XML, not should it be with your DataObject. However, I would put it with a View (template.)

[448191]

I think you misunderstand, I'm not talking about markup, I'm talking about a subclass of a class currently named BB_DataObject_Xml. Used to manipulate Xhtml documents, that will eventually be output.

So I guess the real question is: when can logic be considered "presentation logic", and ordered as part of the view... The class can both load basic templates (I refer to as "Xhtml frames") or make a document from scratch.

A similar issue with my BB_Output class. It handles HTTP headers (although I plan on separating that) and assembles the final document from regenerated and cached chunks.

My thoughts now:

BB_DataObject_Xml (Xml document manipulation)
BB_DataObject_Xhtml (xhtml specific document manipulation, inherits functionality from BB_DataObject_Xml)
BB_View_Document (assemble final document)
BB_View_Header (send appropiate headers)

[Jenk]

So it's using the xhtml page/file as it's datasource?

BB_DataObject_Xhtml

[448191]

Asuming we're using the same definition of "data source", then yes and no.

It CAN use a Xhtml template, or "frame" as you will, as a datsource, but it is also able to create a document from scratch, were different classes create diffent parts of the tree, eventually creating a full document.

[Jenk]

I'd seperate that, as that is dual functionality. Have one object, as a datasource, another as a view.

DataSource fetches existing markup, model does the crunching and instructs the view to 'fill in the blanks'