Update:Archive/2.0/Developers/Tools: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[Update:Home_Page|Update: Home Page]] » [[Update:Development|Development]] »
{{AmoArchive}}


== Development Tools ==
== Development Tools ==
Line 7: Line 7:
== Database Abstraction ==
== Database Abstraction ==


There is discussion between DB:Pear and ADODB.  We need to find the best tool for the job.
There is discussion.  We need to find the best tool for the job.


== Templating ==
=== Goals ===
We need a DB abstraction layer to:
# Ensure portability to different RDBMS products/version
# Ensure a single and manageable practice to perform variable sanitizing against SQL-injection (i.e. binding in prepared statement fashion)
# ''Put your reason here''


What are we going to use for templating?
=== Candidates ===
* [http://adodb.sourceforge.net ADOdb]
* [http://pear.php.net/package/DB Pear::DB]
* [http://pear.php.net/package/MDB Pear::MDB]


=== morgamic's take ===


A solid application structure could eliminate the need for a comprehensive templating engine.  Wrapping HTML output is a relatively simple task done by using includes in parallel with proper use of CSS.  I always question templating that extends beyond that in terms of complexity.
=== Why ADOdb ===
* Meets goals 1 and 2
* More performant (and partially ported in C)
* ''Put your reason here''


As with PEAR::DB or adodb, I think the use of a templating engine should only be considered if it is the right thing to do.
=== Why Pear::DB ===
* Meets goals 1 and 2
* It is old, stable and widely used
* ''Put your reason here''


That said, I question whether adding the layer of complexity and adding another dependency is really necessary if we can use CSS for all of our presentation.
=== Why Pear::MDB ===
* Meets goals 1 and 2
* More portable
* ''Put your reason here''


Don't get me wrong -- I'd definitely like to se HTML wrapped in functions where appropriate and a good segregation of PHP and HTML in order to have some sort of uniformity and structure when it comes to each .php script.  I think that is a great goal and should definitely be realized in any good application.
== Templating ==


But if we can use CSS properly, all HTML output will be exactly the same with the exception of DOM identifiers when appropriate, using templating or skinning the whole app should be reduced to a matter of switching stylesheets.  From there, it's just a matter of packaging your markup properly, which is not something I see us needing a separate tool for.
This section has moved to its own [[Update:Development:Templates|page]].

Latest revision as of 00:53, 29 April 2007

« Back to Archive | Update: Main

Ambox outdated.png THIS PAGE MAY BE OUTDATED
This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution until this flag has been lifted. Help by editing the article, or discuss its contents on the talk page.

Development Tools

This section will serve to outline what frameworks and tools we will be using for the development of the UMO service.

Database Abstraction

There is discussion. We need to find the best tool for the job.

Goals

We need a DB abstraction layer to:

  1. Ensure portability to different RDBMS products/version
  2. Ensure a single and manageable practice to perform variable sanitizing against SQL-injection (i.e. binding in prepared statement fashion)
  3. Put your reason here

Candidates


Why ADOdb

  • Meets goals 1 and 2
  • More performant (and partially ported in C)
  • Put your reason here

Why Pear::DB

  • Meets goals 1 and 2
  • It is old, stable and widely used
  • Put your reason here

Why Pear::MDB

  • Meets goals 1 and 2
  • More portable
  • Put your reason here

Templating

This section has moved to its own page.