drbowen wrote on Friday, April 08, 2005:
Andres has proposed the following:
group based management,
a general road map,
coding standard,
Uniform coding structure and rules.
Uses GACL,
Uses ADODB for everything. (so its truly portable)
Uses CSS instead of html definitions.
documentation standard,
patching process standard,
other third party tools integration,
And I believe:
We should work toward integration of FreeB 2.0 into place of FreeB 1.0
sunsetsystems wrote on Friday, April 08, 2005:
This sounds good to me.
I would add "avoid third party tools with no clear benefit". Projects with many dependencies are hard to install and hard to maintain.
I’m thinking in particular about Smarty which in addition to the above drawbacks slows things down, but there are plenty of other tools which might be tacked on in the future that should not be. Phppgacl on the other hand is a clear winner.
– Rod <rod at sunsetsystems dot com>
anonymous wrote on Friday, April 08, 2005:
I agree with Rob, that "avoid third party tools with no clear benefit".
Nikolai
drbowen wrote on Friday, April 08, 2005:
I am definitely a fan of clean and simple.
Patching in third party tools could potentially introduce licensing conflicts.
tekknogenius wrote on Friday, April 08, 2005:
So, who is going to write the first draft of the coding standards? I can offer some ideas, but my writing skills are lacking.
tekknogenius wrote on Friday, April 08, 2005:
We also need to get a project list (to go along with the roadmap) so that we can volunteer for tasks. In order for stuff to get done we need to know who’s working on what and appoint a “lead” for each piece. I think that will help in it getting done (each person takes responsibility for a task).
sunsetsystems wrote on Friday, April 08, 2005:
Why don’t you do a first draft anyway. It will get cleaned up eventually.
– Rod <rod at sunsetsystems dot com>
sunsetsystems wrote on Friday, April 08, 2005:
Realistically, if I have a client that needs something done then I am going to make sure it gets done (in a way that is also useful to the community), and then hope that the project accepts it. But coordination of effort is definitely a good thing.
– Rod <rod at sunsetsystems dot com>
drbowen wrote on Friday, April 08, 2005:
The reason I posted the OpenEMR wish list is help start this roadmap. I’ll have Emily clean it up, organize and then repost.
We will be glad to help writing the standards.
drbowen wrote on Friday, April 08, 2005:
I have some issue with ADODB. I have run into a least one problem with the ADODB not pulling images out of the database correctly.
ADODB is one of the third party plugins that we have been using routinely.
Does anybody have experience with PEAR vs. ADODB?
And do will really need the ADODB?
andres_paglayan wrote on Friday, April 08, 2005:
I agree with the third party tools thing and we have to take a decision about Smarty also,
Smarty is a tool for building templates.
it separates the process from the display,
i.e. a page process has 700 line of code,
the display it’s only 20 lines.
with smarty you process everything within the script and at the end you invoke the display function.
the template hast a meta-code, things such as { output here} and other control structures such as if and while,
It may speed development, I will say that the only drawback is that we have to learn another tool (about 8 hrs of reading and practicing)
and if we decide to use it has to be used for almost everything, not just occasionally (as part of the coding standard)
this class is what is used in clearhealth for the calendar,
http://pear.php.net/manual/en/package.datetime.calendar.intro-purpose.php
looks very easy to understand and use, it is much more clear than postnuke
emilykillian wrote on Friday, April 08, 2005:
Gentlemen,
I think the consensus here is that someone needs to maintain the project list and coding standards. I will be glad to be the writer/maintainer of those. Please e-mail me any additions you’d like to make to either list. It’s emilykillian at charter.net.
I will post the project list for the community to review/make comments on as soon as I get it in good form.
The coding standards will probably take a little more time. I will post these as it comes along so you’ll all have a good chance to give me input.
Any objections?
andres_paglayan wrote on Friday, April 08, 2005:
I agree on having Emily as the maintainer for both,
In my opinion we should all make a draft and take the best of every one.
I’ll post mine on Monday.
Another idea might be asking physicians, billing personnel, and assistants to log their wishes.
sunsetsystems wrote on Friday, April 08, 2005:
There’s another drawback to Smarty: it’s slow. See my previous message about the calendar:
https://sourceforge.net/forum/forum.php?thread_id=1253770&forum_id=202506
Also for what it’s worth you can easily separate process from display using plain old PHP. The example of “{ output here }” becomes “<? echo $output ?>” with PHP. Either way it’s stuff that is embedded into normal HTML. That’s what PHP is all about.
– Rod <rod at sunsetsystems dot com>
sunsetsystems wrote on Friday, April 08, 2005:
Emily, you have my enthusiastic support. Thanks!
– Rod <rod at sunsetsystems dot com>
sunsetsystems wrote on Friday, April 08, 2005:
Oh, one other thing. Smarty has severe deficiencies as a programming language. For example it does NOT have general-purpose "while" nor "for" statements, so you are very limited as to the types of looping and other control structures that are possible. In the real world, problems can be complicated and user interfaces complex. The last thing we need is a mandated tool that cannot do what we need.
While not being a Smarty expert, I have learned enough about it to question if it even solves *any* legitimate problem in PHP. Does it?
– Rod <rod at sunsetsystems dot com>
andres_paglayan wrote on Friday, April 08, 2005:
the only problem Smarty solves is separating programing from design. It only helps keeping code and design clear so a graphic designer can mess with the template without breaking the code
we can dump smarty and adopt sort of coding standard that says: (when possible) all process should go at the begining, when you are done, render the output at the end. so it’s kept separated but in a single full speed php script.
sunsetsystems wrote on Friday, April 08, 2005:
Sure. You can even have two separate scripts if you want - just have one include the other.
– Rod <rod at sunsetsystems dot com>
tekknogenius wrote on Saturday, April 09, 2005:
Thanks.