On Sat, Nov 27, 2010 at 3:43 PM, unsolicited <span dir="ltr"><<a href="mailto:unsolicited@swiz.ca" target="_blank">unsolicited@swiz.ca</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Khalid Baheyeldin wrote, On 11/27/2010 10:19 AM:<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Sat, Nov 27, 2010 at 1:54 AM, unsolicited <<a href="mailto:unsolicited@swiz.ca" target="_blank">unsolicited@swiz.ca</a> <mailto:<a href="mailto:unsolicited@swiz.ca" target="_blank">unsolicited@swiz.ca</a>>> wrote:<br>
<br>
Since you are already using spreadsheets but consistency is the<br>
issue,<br>
why not use Google Documents, which has hosted spreadsheets, that<br>
people can collaborate on simultaneously.<br>
<br>
<br>
I've tested Google Docs. There is no data consistency / validation<br>
facilities within it. It just hasn't gotten that far, yet.<br>
<br>
And you can also upload your existing Open Office sheets in it,<br>
so setup<br>
is quick.<br>
<br>
<br>
Yes. But, for example, I uploaded to it with some cells data<br>
validated. Then brought it right back - the data validation was<br>
gone. I tried it both ways - they have 2. One that facilitates<br>
online editing as well, the other where it is merely storage. I did<br>
not expect the storage to change the file, but it did.<br>
<br>
Google Docs won't do here.<br>
<br>
<br>
It seems that you already have logic inside your spreadsheet, and that gets<br>
lost when you upload the sheet. You may be using OpenOffice specific<br>
validation or macros.<br>
</blockquote>
<br></div>
And your point is?<br>
<br>
i.e. That's the nature of the beast.</blockquote><div><br>That is the nature of the beast, if you allow it to. If you use Excel or Open<br>Office Spreadsheet as an application development tool and allow your <br>data and code to be intermingled, then that is what you get.<br>
<br>A little of that is perhaps OK, but when it sprawls, you are in for a lot of <br>pain for the long run, for the reasons I stated.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This is the start of "code sprawl". Instead of spreadsheets being just data,<br>
they contain code (business logic) in them, and in effect, you have an<br>
"application".<br>
</blockquote>
<br></div>
Yep, that's the nature of the beast. People do what they can, to the extent that they can, with the tool they have in front of them.</blockquote><div><br>And then suffer later. They either find that the hard way, after they have<br>
the bulk of their business logic and code in the sheets. If they are for-warned<br>and disciplined, they should not allow that to happen.<br><br>Separate the data from the code from the presentation and you will get far<br>
less headaches over the long run.<br><br>This is the same reason we have MVC (model/view/controller) and all this<br>separation of code from presentation (e.g. a theme in Drupal should be where<br>all the presentation stuff). Mix it up, and you get trouble.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
An application is something you have to maintain for many years to come:<br>
debug, modify, extend, ...etc. They have a life of their own, and require<br>
time and effort to continue to exist. Application development is not a one<br>
time thing. It is an on going effort.<br>
</blockquote>
<br></div>
Yes. Nature of the beast. Been doing this stuff for almost 30 years. I knew what I was signing up for when I volunteered to help out.</blockquote><div><br>As long as you know the pitfalls ...<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
At least with Google, your data is still downloadable, and they will not shut<br>
down for some time.<br>
</blockquote>
<br></div>
Arguably, Google fits your prior paragraph. Nothing says the data will be retrievable in a suitable format in the future. </blockquote><div><br>It is retrievable NOW as an Excel sheet, OpenOffice sheet, as well as .txt, <br>
.csv, and more.<br><br>Read about it here: <br><a href="http://docs.google.com/support/bin/topic.py?topic=15148" target="_blank">http://docs.google.com/support/bin/topic.py?topic=15148</a><br><br>They have a team about Data Liberation", and specifically address Docs here<br>
<br><a href="http://www.dataliberation.org/google/google-docs" target="_blank">http://www.dataliberation.org/google/google-docs</a><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The Glom path seems like a good one too. If you don't mind sticking with<br>
their data format for the future.<br>
</blockquote>
</div><br>
In poking around, it does seem like that is inevitable. If, by data format, you are referring to the 'code' that surrounds the data itself. e.g. An OpenOffice form / document / spreadsheet / database. Move to anything else, and the wheel will have to be reinvented in that new environment. And environments are going to inevitably change, over time. Particularly as each new kid on the block appears.<br>
</blockquote><div><br>True to a certain extent that you have to rework things when you change apps.<br><br>But you always want to have a migration path. If the new app provides an import option, then you are good, at least for the data part. If not, then having the data in some standard helps a lot, e.g. CSV export, or relational database.<br>
<br>You can then "fit" the old data to the new app, rather than having to guess the file structure, record padding and/or record alignment, endianess, ...etc.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As I indicated, the significant value of spreadsheets, at the moment, is the users can work with it to explore and discover wherever it is they are trying to go. When that settles down, the system requirements will also become more complete. In essence, they are prototyping, and that's no bad thing. At least, with this mechanism, they are able to, on their own. Further, by establishing some data validation rules, they inherently refine those requirements.<br>
</blockquote><div><br>Largely agree. <br><br>Given the nature of the organization and that they are prototyping, this is an acceptable scenario.<br><br>Otherwise, I would say that validation belongs to the application layer. Whether you implement it as javascript in the browser, or in the backend code, or both (to have instant usability for those who have JS enabled, as well as a fool proof way that applies when it is disabled).<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Right now, I'm not entirely convinced they should move beyond spreadsheets. The back end data extraction requirements are not well defined / known / understood at the moment - it is still evolving. Largely I'm not convince because I think they will need to be able to work against any database moved to, in a spreadsheet, to explore, mash, mangle, discover, etc. Currently, OpenOffice, even against Base, is just broken when connecting to things via data source / calc. </blockquote>
<div><br>Something I remembered: sometime back I was able to connect OpenOffice to a backend of MySQL via ODBC, on Linux (both front end and backend).<br><br>That is something to consider, since it can potentially give you the best of both words: front end in the familiar OpenOffice and a backend on a relational database.<br>
<br>But not sure how/if a spreadsheet would interact with that. Maybe it is limited only to Base?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
e.g. Within the data source view, one can directly edit the database - there goes your data validation, formatting, input controls. Multiple ways of inputting a record to a database would seem to be a very bad thing here. </blockquote>
<div><br>That is why an app should have back end logic, and only that logic would be the one to write to the database. <br><br>Or use triggers/stored procedures if you lean that way. Makes the app tied to one particular database engine though, and makes portability near impossible ...<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I have hints, though, that a Base database connecting to an external server/file (e.g. MySQL or .dbf) has the same issues. I may have to play - which is part of the point of my post: I can download MySQL, but there is no IDE / front end for application development surrounding it - thus the part of my post about what FOSS is out there to use from an IDE perspective.<br>
</blockquote><div><br>Valid point (lack of IDE).<br></div></div>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com" target="_blank">2bits.com</a>, Inc.<br><a href="http://2bits.com" target="_blank">http://2bits.com</a><br>
Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>
Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>