php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #56710 SDO_DAS_XML->saveDataObjectToString() without SDO_Model_ReflectionDataObject...
Submitted: 2005-12-08 14:52 UTC Modified: 2006-10-30 06:30 UTC
From: bjori@php.net Assigned: mfp (profile)
Status: Closed Package: SCA_SDO (PECL)
PHP Version: 5_1 CVS-2005-12-08 OS: FreeBSD6.0
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bjori@php.net
New email:
PHP Version: OS:

 

 [2005-12-08 14:52 UTC] bjori@php.net
Description:
------------
Feel free to 'Wont' fix' this one but I was happy with SDO_DAS_XML->createDataObject()->getType();
Feels quite weird to create an instance of SDO_Model_ReflectionDataObject just to be able to write the XML out.

I actualy don't realy want to call getType at all. SDO_DAS_XML->saveDataObjectToString() should, IMO,
take the type of the first argument by default.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-12-12 09:02 UTC] mfp@php.net
Hi Bjori (is that your name by the way?),
I agree with you that introducing the ModelReflection stuff is rather ugly. I didn't like it myself. 

Actually there is a confusion/complication. The thing you need to pass to saveDataObjectToString is the name of the document element name not its __type__. So for example you might pass "company" and get xml with <company>...</company>. The docs were at best amiguous and the example in them was just plain wrong (although now fixed on the livedocs version). What you are going to get back from getType is the type e.g. "CompanyType". I expect it worked for you because your type name and element name were the same? 

We know we need to have an overhaul of the user interface for the XML DAS but have not worked out what to do yet. We will try to incorporate your suggestion that saveDataObjectToString should just do the right thing.
 [2005-12-12 09:58 UTC] bjori@php.net
Hi Matthew,
 sorry for leaving out signature - my name is Hannes :)

My type and element names where the same, in this case, yes.
I've been wondering alot about strange results from saveDataObjectToString() from time to time, now I know why, hehe.

The docs are/were quite confusing on how to call saveDataObjectToString correctly - without having to manually type in "shitload" of info ;)

How about doing something like ext/dom does, DOMDocument->saveXML(), for instance, spits out the whole document, by default, but you can ask it to treat specific element as root?

Thanks for the response
- Hannes :)
 [2006-02-24 10:11 UTC] mfp@php.net
Hi Hennes, it's been along time coming but we recently put out our 0.9.0 release. Along with some rearrangement of the API for the working with XML, which might hurt a bit (sorry, but we felt it was needed), we did bring back the functionality we had with getType(), although it is now two separate calls, getTypeName() and getTypeNamespaceURI().

And we no longer have saveDataObjectToString() exactly as we used to have it; we now require that you have to have a document to contain it. If you want to serialise a data object you need to have it in a document object and write that out with saveString. If you want to suppress the XML declaration that you would normally get with a document then you can call setXMLDeclaration(false) first.
 [2006-03-01 12:14 UTC] bjori@php.net
High five for saveString()!
Works like a charm and exactly what I was hoping for :)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 11:01:30 2024 UTC