thats a good idea, id go a step further and return a JSON object or XML, and have it parse the XML or JSON object on the client side with javascript, so they can customize the HTML structure on their end. That way you send them a model not a view, and you let them generate a view. Then they can switch views on their end with a flag as wellthinsoldier wrote:And for them it would probably be best to return simple, valid html that they can easily style with CSS to fit their site.
Sharing data between websites
Moderator: General Moderators
Re: Sharing data between websites
-
jeffrydell
- Forum Commoner
- Posts: 77
- Joined: Thu Jan 17, 2008 4:39 pm
- Location: Menasha, WI
Re: Sharing data between websites
In theory, sending back plain XML would be the ideal solution from my end. In reality, however, the data needs to be formatted to match THEIR site when I send back the result. For the most part, my clients are not at all sophisticated or web savvy and anything I ask them to do is the equivalent of climbing Mt. Everest.
Example. I collect data for them. In some cases it's too hard for some to download the file with data in XML format and run an import application to place all that data in an Access-based desktop app. They get messed up with seeing the XML, saving in the wrong place, who knows what - but ANYTHING has to be presumed to be "too hard".
That's why my php 'client' script is set up the way it is ... so I can identify who's asking - run their query ... pull the result set from my database, and return the formatted string in HTML so it just needs to be echoed to the screen. ONE include for them - that's it.
On my end, I can have a separate 'formatter' script for each client and run that on the server before sending the results back.
I'd much prefer to have a straight forward XML request and return the result set in XML to let them 'make it pretty', but it's just not realistic to expect that the clients will be able to handle that task.
Make sense?
Example. I collect data for them. In some cases it's too hard for some to download the file with data in XML format and run an import application to place all that data in an Access-based desktop app. They get messed up with seeing the XML, saving in the wrong place, who knows what - but ANYTHING has to be presumed to be "too hard".
That's why my php 'client' script is set up the way it is ... so I can identify who's asking - run their query ... pull the result set from my database, and return the formatted string in HTML so it just needs to be echoed to the screen. ONE include for them - that's it.
On my end, I can have a separate 'formatter' script for each client and run that on the server before sending the results back.
I'd much prefer to have a straight forward XML request and return the result set in XML to let them 'make it pretty', but it's just not realistic to expect that the clients will be able to handle that task.
Make sense?
-
thinsoldier
- Forum Contributor
- Posts: 367
- Joined: Fri Jul 20, 2007 11:29 am
- Contact:
Re: Sharing data between websites
So your clients are business people trying to run their business & their website themselves instead of hiring a proper web developer?
Warning: I have no idea what I'm talking about.
-
jeffrydell
- Forum Commoner
- Posts: 77
- Joined: Thu Jan 17, 2008 4:39 pm
- Location: Menasha, WI
Re: Sharing data between websites
Yepthinsoldier wrote:So your clients are business people trying to run their business & their website themselves instead of hiring a proper web developer?
Re: Sharing data between websites
What I had in mind was some sort of .js file they'd copy over, and they'd put something like
<script href="xmlParser.js" />
<div id="xml_reuslts"></div>
<script>loadXML();</script> <!--- calls loadXML() from xmlParser.js -->
then the loadXML() function would build the HTML and output it to the div. Instead of XML if you use JSON ( which theres plenty opensource solutions for both PHP and javascript ) then you don't have to parse any XML either, updating the HTML is as easy as giving them a new xmlParser.js, then you can run multiple clients with multiple setups without having your view intertwined with your business logic. CSS is great for styling, but falls short for a lot of layout issues where a different HTML structure would be needed, for instance some CSS effects can only be done on unordered lists display as block elements, while others only work on links as inline text, etc.. you could even go back and "ajax"-ify it, without having to touch your feed
If you keep your display logic separate its going to pay off in the long run
<script href="xmlParser.js" />
<div id="xml_reuslts"></div>
<script>loadXML();</script> <!--- calls loadXML() from xmlParser.js -->
then the loadXML() function would build the HTML and output it to the div. Instead of XML if you use JSON ( which theres plenty opensource solutions for both PHP and javascript ) then you don't have to parse any XML either, updating the HTML is as easy as giving them a new xmlParser.js, then you can run multiple clients with multiple setups without having your view intertwined with your business logic. CSS is great for styling, but falls short for a lot of layout issues where a different HTML structure would be needed, for instance some CSS effects can only be done on unordered lists display as block elements, while others only work on links as inline text, etc.. you could even go back and "ajax"-ify it, without having to touch your feed
If you keep your display logic separate its going to pay off in the long run