Re: [ODP-dev] A good place to start developing. [was: RFC: A new directory structure for OpenDocumentPHP]

[Daniel L. <dlo...@gm...>]

Team:

I spent a few hours today (while at work, luckily it was a slow day)
reviewing a number of things, including the most recent version of the
source code and the OASIS ODF specification to get a better handle on
everything. While complex initially, it is already making a great deal of
sense. In addition, Norman, your email comments helped a lot in clarifying
the issues and questions in my mind. I have thus begun work toward the task
I mentioned I would attempt: a basic webpage to create an ODT file on the
fly.  I did not understand one thing you said, the line

" (Please you a production code statement
at the beginning, like require_once 'OpenDocumentPHP/...' and not the one
in the test file require_once '...'!)"

You are clearly referring to include statements for classes in the project.
My lack of familiarity with the project or perhaps some newness to PHP leads
to a very basic question: what should I put? I am leaning towards thinking
that the format you want is an absolute path
require_once statement to the root of the OpenDocument code. In other words,
when I proceed to use the OpenDocumentText class, are you saying I should
do:

require_once('OpenDocumentPHP/OpenDocument.php');

and I were to use DublinCoreFragment, I should do

require_once('OpenDocumentPHP/meta/DublinCoreFragment.php');

If I have totally misunderstood, please show me (it will only take once) and
I will do right from now on.

I should say, before we get too far into this, that I will take any and all
criticism of my coding style or logic. I have programmed for a long time but
have little formal training in matters such as version release and team
programming. I am always open to suggestions and refinements to better
improve my skills and our project and will not take what you say personally.
(obviously you mentioned refactoring as a project-wide series of a constant
refinements).

To wrap up, my sourceforge username is dlongest (should be easy to remember
:-)  I hope to have something (useable is the wrong word) demonstrative by
the end of the week to be examined, prodded, and inspected as my first
project submission.  I am using xampp to run Apache and PHP locally for my
test client. Are we running production code with superglobals turned on or
off? I want to make my local environment as close to the production
environment as possible.  If these questions are answered in another already
written resource, please direct me to it and I will answer as much as I can
for myself.

Regards,
Dan

On 2/20/07, no...@se... <no...@se...> wrote:
>
> Hi Dan et. al,
>
>
> Daniel Longest wrote:
> > Norman et al:
> > Sorry for the several day delay on my response.
> we are all doing this as a hobby in our spare time, not as a job, so you
> don't need to apologize  for any delay.
> > > - some examples, a webpage, for instance, where you could write some
> > > lines. Fill in some meta data forms and we make a odt out of it.
> >
> > This one, at least on its face, appears to be the "easiest" for a new
> developer to the project. If I am understanding you/the project
> correctly, I would need to basically provide the functionality to
> convert a basic web page with form to an ODT. Is that correct?
>
> Okay, I will concrete my thoughts a little bit more:
>
> I would like to see a webpage with a (or some) forms, where you can input
> some (plain) paragraphs and some meta data (like the file name, the
> creation date, the initial creator ... what ever you find interesting in
> the DublinCoreFragment and MetaFragment classes in the src/meta directory)
> and then press a button and you can download a freshly made
> OpenDocumentText. This webpage should also be on our website
> (http://opendocumentphp.org) as a short demo.
> A good start should be to take a look at the
> src/samples/OpenDocumentTextTest.php file and get rid of the "test" stuff.
> You should easily get the code you need to create a OpenDocumentText. The
> missing part is the website stuff. (Please you a production code statement
> at the beginning, like require_once 'OpenDocumentPHP/...' and not the one
> in the test file require_once '...'!)
> > > - the manifest class has some missing functionality, which should be
> > > 'easiely' added by some one...
> >
> > Forgive my ignorance and I apologize if this is answered in the project
> docs, but I'm currently unfamiliar with the manifest.
> Okay, the manifest is the basic directory of an OpenDocument package.
> Every file you put in the OpenDocument package is listed in two places.
> The first place is in the zip file directory, this is done automatically
> by the ZIP class. The second place is in a special file, called the
> manifest. This is very similar to the MANIFEST.MF you will find in every
> (good) JAR file. Sun has decided to spend OpenDocument also a manifest,
> but one in XML style. So every OpenDocument packages has a manifest.xml in
> witch you can find all the files in the OpenDocument package with some
> extra data.
> Currently we support only the main parts of this manifest. But you can
> also add some more data. More informations about this are in the
> OpenDocument specifications.
>
> > > - currently we are working on the text (and more or less on the
> > > spreadsheet) part of a OpenDocument. The *:number format stuff is
> needed
> > > by both parts in a way. This could be a good staring point for some
> new
> > > classes.
> >
> > If I understand this part correctly, you are talking about the actual
> grunt labor of converting a text file to OpenDoc, specifically dealing
> numeric formatting (which can be shared across multiple parts for such
> formatting as needed).
> I will give response to that part later, okay?
>
> > I am leaning towards working on the first task that I quoted,
> translating meta data webpage forms into ODT, assuming I understood the
> objective.  What is the "best" way to test my code? I guess a way to
> rephrase that question is: where can I (or should I be using) a
> standalone PHP interpreter? Or is the "best" way simply through a
> locally installed Apache webserver configured with PHP?
> The best thing for the first subproject is to start with a local Apache
> webserver, I think (WAMP or XAMP or ... ???). You should check that you
> have PHP 5.2.0 or 5.2.1 running on the server. After that, install the
> current _production code_ and write some code that will run under Apache
> in PHP (or was in in Apache under PHP???). If you got it, tell us and we
> will include this in the source tree.
>
> > I realize some of these questions are rather simple but I want to make
> absolutely certain I understand the basics before wreaking havoc :-)
>
> No problem, mostly my faults.
>
> I know, I should talk more about what I am thinking on this list (or in my
> blog) and I promise to do so....
>
> Yours,
> Norman
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> OpenDocumentPHP-Developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opendocumentphp-developers
>