RE: [tcdb-devel] Organization of tcdb2.php cvs module

[Matthew H. <mhi...@vi...>]

I think that these are all excellent ideas. The only new thought that I have
to add at the moment is a reminder that we need to select some sort of
logging facility to use for our portion of the code.

 

As far as securing php files, I believe (though I may be mistaken) that php
include/require statements can point to an absolute file in the file system
as opposed to a relative/absolute URL (actually, I believe that it's the
recommended practice, though it's possible to make the statement reference a
URL). With this as the case, I think that we can store said files in
/etc/tcdb/ or /usr/etc/tcdb/, secure them so that they only have
read/execute access by wheel, and be set. I definitely agree that the only
publicly available files should be those that actually generate content the
user directly sees. Also, we should consider a statement at the top of each
file that restricts the file from being run if it is run directly (I know
that I've done/seen it before, so I'll look around for this snipit of code).

 

Also, something that we probably should keep under consideration is allowing
for usage under Windows/IIS.

 

--Matt

 

  _____  

From: tcd...@li...
[mailto:tcd...@li...] On Behalf Of Jason Corbett
Sent: Wednesday, December 15, 2004 6:15 PM
To: Jason Corbett
Cc: tcd...@li...
Subject: Re: [tcdb-devel] Organization of tcdb2.php cvs module

 

Sorry for the big email, but I've thought of some things, and I'm expecting
some feedback on this.

Alright, I've had some time to think about it, and I'm not sure on the copy
'n run idea.  There are a couple of issues:

1.	We want this to work for Mysql and for Postgres out of the box (I
think we should also consider sqlite for demo purposes, but we can start
another thread on that).  I'm almost positive that the class files that are
generated (not the subclass ones we edit, but the parent persistent ones)
are different for the different databases.  I could be wrong, maybe creole
handles this, we may want to investigate it, but at any rate we'll need 2
different builds of the sql file.

I think that a better way to handle this is that we should have a build
system based on phing, that does the generation/install dynamic.  This way
we can script it as we need, and we have a much cleaner cvs/distribution.
2.	After going through and trying to custimize the propel-gen script so
that we could make the directories live in the places we want, I realized
that it would be much easier to customize it if we distributed
phing/creole/propel in our cvs, and then used our own build process.  I
could probably get it done in a day.  It would make a lot more sense than
having to say as part of the install - follow the instructions from propel
to install the propel runtime.  We should distribute this stuff, it isn't
really big, and I don't think any of it is native code.

So my proposal is this:

1.	We have an installer / build system with the following requirements:

*	shell based, not to restrictive since this project is meant as an
intranet system.  Some projects use a web based installer, but I find that
the reason they do this is for people deploying it that only have ftp
access.  Our potential users don't typically fit into this category.
*	It should request the information on what database to use, what
username/password, etc. from the user.  All information to get it basically
set up and running, no editing of properties files/config files.  The
properties it asks for should be minimal (ie enough to get it up and running
with an admin user).  All other settings should be customized within the web
interface.
*	We should have a uninstall/wipe.  Maybe wipe is more accurate.  The
reason for this is that we want dev people (us) to be able to update from
cvs, and to quickly deploy the latest schema.  Most of this is already in
the sql generation.
*	The ability for non web php files to live outside the web root.  I
find one of the most annoying things about securing a php application is
that you have to edit .htaccess files for all the dirs that have php files
that shouldn't be accessed through the web (like a config.php should never
be accessable directly).
*	Much easier install on apache2 systems / newer versions of Redhat,
SuSE, and debian if possible.  We won't garuntee anything, but apache2
installs almost always have the ability for individual applications to
create their own .conf entry in a separate file that will be read in upon
startup.  I don't think this is a necessary feature to begin with, but it is
one I would like to have eventually.

2.	Directories:

*	build: this contains our version of phing/creole/propel necessary
for the building/installing of tcdb.
*	docs: self explanatory
*	lib: At first I had this as runtime-lib, but that seems kinda long,
so let's just call it lib.  It should contain propel runtime (and of course
creole) and any other dependent / non changing classes (ie ones not specific
to tcdb)
*	backend: all the backend classes, the ones that are generated, and
the ones that we write.
*	frontend: UI stuff.  All the files that need to be in the web need
to be in this dir.
*	tests: What Unit tests for a Tester's project?  Yup, these will help
me verify that the backend works like I think it does, so the person writing
the frontend won't have to find out the hard way that the backend is
completely broken.  I'm not saying that we'll have complete code coverage, I
don't have that much time, but we can at least test things that have been
problems for us in the past (regression).
*	schema: this will contain the tcdb schema.  I've figured out how to
allow for each table to live in it's own xml file for nice viewing/editing.
*	Any others???

3.	Files in root:

*	README: general description of tcdb, and design goals, something no
one will probably read...
*	INSTALL: simple manual on how to get up and running the quickest,
example commands for mysql/postgres
*	installer.php: yup, the installer

4.	Beautifiers:

*	I would like to have php code formatters/beautifiers to keep all our
code consistant in it's look and feel.  I've found this to be very helpful
(I don't have to spend so much time while coding trying to follow some weird
style that I'm not used to, the formatter will take care of it).  I found
one in pear, but I still have to look to see if it's configurable.
*	A html/xml beautifier would probably be good, but maybe not
necessary.  I know I need to run one on the xml I've written for the schema
(make sure all the indentation looks consistent), but someone else can make
that call.

5.	Doc generator for backend:

*	javadoc is nice for learning how to use someone else's classes.
Since we're trying to separate the backend and frontend appropriately, it
might help to have some doc tool to generate nice looking docs from it.
Someone please comment on what you think about this.  If you want to see an
example of a few I found: http://www.phpdoc.de/
http://phpdoctor.sourceforge.net/ www.phpdoc.org (the last one, the web site
created is ugly, however it says it has different templates, we'll see.  It
also has output ability of pdf, chm, etc.)

Please let me know what you think... I want to get moving, but I also want
feedback.  If you think one of my ideas is overdone, that's perfect!

Jason Corbett

Jason Corbett wrote: 

As Matt and I discussed, Sourceforge has been gracious enough to wipe out
what we had in cvs.  Now we can rebuild it like we want...  Umm how did we
want to do that?
 
  In my experience php programs have one awesome quality, copy and run.  I
would like to have everything that is needed to run the web interface in 1
folder.  I propose distribution, but feel free to come up with your own
ideas.  That folder should be the root of the php class paths, and should be
copyable to the web folder, and wala, installed.  Well there might be a few
steps in setting up the config/installing db.  But you get the idea.
 
  Docs should probably live in a folder called docs.  I'm sure I'm missing
some things, but basically distribution (or whatever you want to call it)
should be the main concern as to how it's structured.  Any replies?
 
Jason Corbett

 

------------------------------------------------------- SF email is
sponsored by - The IT Product Guide Read honest & candid reviews on hundreds
of IT Products from real users. Discover which products truly live up to the
hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________ Tcdb-devel mailing list
Tcd...@li...
https://lists.sourceforge.net/lists/listinfo/tcdb-devel