opendocumentphp-developers — OpenDocumentPHP-Developers

[ODP-dev] Hi folks...

[Brice <bri...@gm...>]

Hello,

I recently discovered the OpenDocumentPHP project. I'm looking for a
standard library or classes that help me to create ODT files. This
project seems very interesting but not very active. I discovered and
corrected some minor bugs and i have one important bug when i open the
file.

There is anyone here to help me and, maybe, use my work to update and
release a new version of this project?

Kind Regards,
Brice Favre

[ODP-dev] Read a text content of a .odt file

[J. N. <jon...@gm...>]

Hi Norman and others!

Just like Erik, I want to be able to read the text content of a odt file.
A simple example would be great!

I'm using version 0.5.3

Regards

Jonas Nyström

Re: [ODP-dev] problems with trunk and php 5.2.5

[Lars E. <od...@xa...>]

Hello,

problem solved, my fault :)

Nevertheless, attached a patch set against tag revision 0.5.3. This
patch corrects method definitions for saveXML() and getTag() in various
files for accordance against E_STRICT as well some notices. Additionally
I removed the php end tags in order to avoid messages like "headers
already send", look at Validator.php in the last lines (2 lines
after ?>)

I hope you could integrate it into upstream..

lars


Am Dienstag, den 29.01.2008, 19:36 -0500 schrieb ad...@ya...:
> Lars Erler wrote:
> > hello @all,
> >
> > I'm currently evaluating your classes for a project.
> > Testcase is Debian Etch 4.0 with php5.2.5 from dotdeb and
> > phpopendocument trunk (#282) [0.5.3 same problems]
> >
> > Sample Script is this:
> >
> > [SNIP]
> >
> >
> > Somebody any ideas?
> >
> > lars
> Hey Lars,
> 
> Hmm.. I have just run your file and it is working on both Command line  
> and web-based, they both produced the correct results.. (I only  
> changed the include paths..)
> 
> That error is normally caused when the ZipFile (.odt file), is not  
> opened correctly from what I can gather.. But that would normally  
> output a warning from the Open() (line ~232 (same file as original  
> warning)) as well..
> 
> Is it just that warning that you are receiving? From the tests I have  
> run I cannot manage to get it to output just one error message.. it  
> does it for all four components (content.xml, meta.xml, settings.xml,  
> styles.xml)..
> 
> Can you try printing out the $localname variable in that function  
> (line ~175) and seeing which file is producing the warning..
> 
> Thanks, Alex Latchford..
> 
> PS.. This mailing list isn't very active, neither is the project  
> currently, Norman Markgraf is the real driver of the project so he may  
> have a more comprehensive answer.. :)
> 

[ODP-dev] problems with trunk and php 5.2.5

[Lars E. <od...@xa...>]

hello @all,

I'm currently evaluating your classes for a project.
Testcase is Debian Etch 4.0 with php5.2.5 from dotdeb and
phpopendocument trunk (#282) [0.5.3 same problems]

Sample Script is this:

<?php

/**
 * skeleton batch script
 *
 * Here goes a brief description of the purpose of the batch script
 *
 * @package    dissz
 * @subpackage batch
 * @version    $Id$
 */

// created with symfony init-batch default skeleton backend  
define('SF_ROOT_DIR',    realpath(dirname(__file__).'/..'));
define('SF_APP',         'backend');
define('SF_ENVIRONMENT', 'dev');
define('SF_DEBUG',       1);

require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

// initialize database manager
//$databaseManager = new sfDatabaseManager();
//$databaseManager->initialize();
ini_set('include_path',ini_get('include_path').':../externals/php/opendocumentphp/current/src/:');
require_once('../externals/php/opendocumentphp/current/src/OpenDocumentPHP/OpenDocumentText.php');


/*
 * replace the first '' with a path of your choice or the full path in
$fullpath.
 */
$fullpath = tempnam('', 'SDC');

/*
 * if a parameter was given, than use this parameter as filename. 
 */
if ($argc == 2) {
	$fullpath = $argv[1];
}

/*
 * If demo output exists, remove it first.
 */
if (file_exists($fullpath . '.odt')) {
    unlink($fullpath . '.odt');
}

/*
 * Open a new OpenDocumentText object with filename "$fullpath".'odt'.
 */
$text = new OpenDocumentText($fullpath . '.odt');
/* ------------- */
/* Set meta data */
/* ------------- */
$text->setDefaultMeta();
/* --------------------------- */
/*  Set Font Face Declarations */
/* --------------------------- */
$text->setDefaultFontFaces();
/* ------------------ */
/* Set up some styles */
/* ------------------ */
$text->setDefaultStyles();
/* --------------------- */
/* Write some Paragraphs */
/* --------------------- */
$textbody = $text->getBody()->getTextFragment();

// First we create a headline:

$heading = $textbody->nextHeading();
$heading->setStyleName('Heading_20_1');
$heading->append('Headline');

// Now we write a short paragraph:
$paragraph = $textbody->nextParagraph();
$paragraph->setStyleName('Standard');
$paragraph->append('The first paragraph in the document. ');
$paragraph->append('And this is the 2nd part of this first paragraph.');

// *** FIX ME *** - We should do a lot of other work here...

$text->close();

/*
 * remove tmp file if there is one ...
 */
if (file_exists($fullpath)) {
   // unlink($fullpath);
}

echo "You can find the new simple OpenDocument file here: " .
$fullpath . "\n";
// batch process here

Error Message is this:

Warning: ZipArchive::addFromString()
[function.ZipArchive-addFromString]: Invalid or unitialized Zip object
in /var/www/project/dissz.net.trunk/externals/php/opendocumentphp/opendocumentphp_trunk/src/OpenDocumentPHP/OpenDocumentArchive.php on line 179


This is the code:

/**
	 * Add a file to a ZIP archive using its contents.
	 * 
	 * @param 		string $localname The name of the entry to create.
	 * @param 		string $contents The contents to use to create the entry.
It is used in a binary safe mode. 
	 * @param 		string $mimetype Mime type of the file.
	 * @access 		public
	 * @since 		0.5.0 - 08. Feb. 2007
	 */
	function addFromString($localname, $contents, $mimetype = 'text/text')
{
		/*
		 * First add to ZipArchive ...
		 */
		$ret = parent :: addFromString($localname, $contents);


Somebody any ideas?

lars

[ODP-dev] OpenDocumentPHP 0.5.3 released

[Norman M. <no...@se...>]

Dear Customers and Developers,

the *OpenDocumentPHP Team* is proud to ship the newest code out of our 
SVN repository as *release 0.5.3*. A lot of changes has been made to the 
code to make it faster and more reliable than ever.

The current code is based on the great "/php/tags/0.5.3/" tree in our 
repository. If you want to stay close to the latest code, you can always 
use the "/php/thrunk/" development tree right out of the SVN repository.

This code under development, there could be new bugs. So please report 
any bug you find on the bug tracking system at sourceforge, send a 
message on the mailing list, or report it to one of our developers.

Take a look at our web site <http://opendocumentphp.org> for the lastest 
information about *OpenDocumentPHP* and for our open positions in the 
development team.

For *the OpenDocumentPHP Team*
Norman Markgraf
(team leader)

[ODP-dev] A new website ...

[Norman M. <no...@se...>]

Hi folks,

as most of you may know, I did some work on our website. Currently a 
beta release is running at http://new.opendocumentphp.org and I hope 
switch to this new site by the end of the month. So please take some 
time and test the new site. Any hints and bug reports are welcome.

Yours,
Norman Markgraf

[ODP-dev] The structure of the SubVersion repository.

[Norman M. <no...@se...>]

The SubVersion repository of *OpenDocumentPHP* has three main paths, 
namely “/php”, “/doc”, and “/web”. The software development process will 
find its place in the “/php” path and is itself structured too. The 
other two paths are for the – currently not started- 
(online-)documentation, which should be in the “/doc” path, and the 
Joomla!-Template development, which is in the “/web” path.

Unless you are not a web designer or web developer you do not need to 
get the “/web” stuff, and unless you are not a documentation technician 
and the new (online-) documentation did not started, you do not need the 
“/doc” stuff.

There might be other stuff in the root of our repository, as “/phase1”, 
“/phase1.1”, “/poc”. This is very old stuff and will be removed or 
archived in the (near) future.

So the main development cycle will be took place in the “/php” 
directory. You will find three subdirectory in there:

   1. “/branches”
   2. “/tags”
   3. “/trunk”


The head or main development will be in the “/trunk” part. This is 
always the leading edge of our source code. If you are a developer and 
want to make changes, this is the stuff you need. You can get it via:

svn co 
https://opendocumentphp.svn.sourceforge.net/svnroot/opendocumentphp/php/thrunk 
opendocumentphp

The other two subdirectories have different purpose. The “/tags” 
directory will held our releases. Currently there is a “0.5.3” in it and 
I will make a release of *OpenDocumentPHP* 0.5.3 directly out of the 
“/tags/0.5.3” source code. It is a kind of release history so to speak.
If a release is ready to be build and shiped, the release manager will 
copy a snapshot of the “/trunk” directory right into a new 
“/tags/<release>” directory. After he or she did that she or he can 
simple checkout this tag and make the distribution and PEAR releases out 
of it. - I am currently working on some (shell-)scripts to make this as 
easy as possible. That is the main reason why 0.5.3 is not shipped by now.

The release naming convention of *OpenDocumentPHP* is currently X.Y.Z, 
where X is the major release number (currently 0, to show that we are 
still not stable), Y is the minor release number (currently 6) and Z is 
the sub-minor release number.
Every major-/minor release number have it own branch. So the last 0.5.Z 
development stuff will always be found in the “/branches/0.5” 
subdirectory, if there will be ever a bug fix necessary for 0.5.3 a 
developer can easily take the “/branches/0.5” as starting point, make 
the fixes and public a new 0.5.4 release. Which means he makes his 
changes to the “/branches/0.5” code base as long as he is ready and if 
it is tested, he or she can create a new “/tags/0.5.4” directory and 
start the publication process for the “0.5.4” bug-fix-release.

At that time in the future, where we will be changing from 0.6 to 0.7 
the last “/trunk” will be copied to the new “/branches/0.6” directory 
and the “/trunk” will be the “new 0.7 trunk/branch” and later (when 0.8 
comes up) become “/branches/0.7” and so on. I hope this gets clear.

[ODP-dev] Current design goals in the thrunk(aka branch 0.5) and branch 0.6.

[Norman M. <no...@se...>]

Hi folks,

as you all know, there are currently two development branches in our 
repository. And I feel, that I need to explain why.

The design goal of the 0.5 branch (a.k.a trunk) is to get rid of the 
ElementFragment and Fragment classes witch currently make the basic 
work, and use the new ODPElement class instead. ODPElement extends 
DOMElement, and has some new methods, which makes a lot of standard work 
easier. The namespaces, which where defined in ElementFragment and 
Fragment, where moved to the Namespace interface. This should make the 
classes a lot handier.

The purpose of the 0.6 branch is to start new Writer classes. So the 
work with ODP will get a lot easier. We start here with a 
re-implementation of PEAR_Spreadsheet_Excel_Writer classes. After that 
has settled, we should start with a Writer class for text document, may 
be in a 0.7 branch or in 0.6. - We should discuss that later...

The next upcoming release will be 0.5.3 (and maybe 0.5.4...) which 
should remove as much of the ElementFragment and Fragment classes as 
possible. After these changes are made, the 0.6 branch will 
resynchronize with 0.5.(3?) and become the new trunk.

If you got any questions about the design goals, the code or the 
strategy ... please ask.

Yours
Norman Markgraf

Re: [ODP-dev] Branch 0.6.0

[Norman M. <no...@se...>]

Hi folks,

the new branch 0.6.0 is now in a state that some else could take it 
over. It is far from being perfect, but this little code fragment will 
produce an spreadsheet document, that could be read at least by 
OpenOffice Calc:

<?php

require_once 'OpenDocumentPHP/util/Spreadsheet/Writer.php';

// Creating a workbook
$workbook = new Spreadsheet_OpenDocument_Writer('test.ods');

// Creating a worksheet
$worksheet = $workbook->addWorksheet('My first worksheet');

// The actual data
$worksheet->write(0, 0, 'Name');
$worksheet->write(0, 1, 'Age');
$worksheet->write(1, 0, 'John Smith');
$worksheet->write(1, 1, 30);
$worksheet->write(2, 0, 'Johann Schmidt');
$worksheet->write(2, 1, 31);
$worksheet->write(3, 0, 'Juan Herrera');
$worksheet->write(3, 1, 32);

// Let's write the file
$workbook->close();
?>


A lot of work is still to be done and I will help any volunteer who 
wants to take the branch 0.6.0 and make the part in 
OpenDocumentPHP/util/Spreadsheet/ ready for production.

Please contact me ASAP.

Yours,
Norman

[ODP-dev] New Subversion structure and branch 0.6.0

[Norman M. <no...@se...>]

Hi folks,

I changed the structure of the Subversion repository. You will find now 
the development code in the php/trunk directory. So if you want to 
checkout the latest development code, please try:

    svn co 
https://opendocumentphp.svn.sourceforge.net/svnroot/opendocumentphp/php/trunk 
opendocumentphp

There is also a new branch for the 0.6.0 development, Andreas please 
take a look at it, in which I made the first steps for a new Spreadsheet 
support.

You all might know PEAR_Spreadsheet_Excel_Writer, if not, please take a 
look at it. In the 0.6.0 branch I have started to copy as much of the 
API to our own API. You might take a look at 
OpenDocumentPHP/util/Spreadsheet in the src tree. Be aware, that I said, 
I have started. It is much more than not complete. But I hope I will 
find some of you helping me there.

As this is a part of the next 0.6.0 code base, I put this development 
not in the trunk but in the branches tree. So if you want to take a look 
at that part, please try:

    svn co 
https://opendocumentphp.svn.sourceforge.net/svnroot/opendocumentphp/php/branches/0.6.0 
opendocumentphp-0.6.0

Thanks to you all, especially to Roland Wintgen for the nice discussion 
about PEAR(_Spreadsheet_Excel_Writer) and Guido Klostermann for find 
some bugs in the documentation.

Yours,
Norman Markgraf
(project leader)

[ODP-dev] PEAR Package ...

[Norman M. <no...@se...>]

Hi folks,

I just want to inform you, that you can get OpenDocumentPHP as a PEAR 
package.

Just try:

:> pear channel-discover pear.opendocumentphp.org
:> pear install opendocumentphp/OpenDocumentPHP

Thanks,

Norman

[ODP-dev] OpenDocumentPHP 0.5.2 released

[Norman M. <no...@se...>]

Hi!

the OpenDocumentPHP team is proud to ship the newest code out of our 
repository as release 0.5.2. A lot of changes has been made to the code 
to make it faster and more reliable than ever.

The current code is based on the great “phase1.1” tree in our 
repository. If you want to stay close to the latest development, you can 
always use the “phase1.1” code tree right out of the repository.

Most of the former bugs where fixed and the source is much more 
documented than 0.5.1. But as every code under development, there could 
be new bugs. So please report any bug you find on the bug tracking 
system at sourceforge, send a message on the mailing list, or report it 
at least to one of our developers.

Take a look at our web site http://opendocumentphp.org 
<http://opendocumentphp.org/> for the lastest information about 
OpenDocumentPHP and for our open positions in the development team.

Norman Markgraf

Re: [ODP-dev] Read ODT file

[<no...@se...>]

Hello Erik,

could you please tell us the release number of you OpenDocumentPHP?

Thanks,

Norman

> Hello,
>
> I want to read an ODT file, modify it and store it.
>
> But using the code below I end up with an blank ODT document
> (and yes, the file exists):
>
>      $text = new OpenDocumentText($fullpath);
>      // doing nothing here
>      $text->close();
>
> I also tried to hack the flag ZipArchive::CREATE inside the
> file OpenDocumentText.php.
>
> The ODT file is quite complex (an invoice). May
> there be any elements in there that opendocumentphp
> cannot process yet and therefore breaks?
>
> Thanks!
>
> Erik

Re: [ODP-dev] Read ODT file

[<no...@se...>]

Hello Erik,

could you please tell us which release you got?

Thanks

Norman

Erik Schmitt schrieb:
> Hello,
>
> I want to read an ODT file, modify it and store it.
>
> But using the code below I end up with an blank ODT document
> (and yes, the file exists):
>
>      $text = new OpenDocumentText($fullpath);
>      // doing nothing here
>      $text->close();
>
> I also tried to hack the flag ZipArchive::CREATE inside the
> file OpenDocumentText.php.
>
> The ODT file is quite complex (an invoice). May
> there be any elements in there that opendocumentphp
> cannot process yet and therefore breaks?
>
> Thanks!
>
> Erik

[ODP-dev] Read ODT file

[Erik S. <eri...@we...>]

Hello,

I want to read an ODT file, modify it and store it.

But using the code below I end up with an blank ODT document
(and yes, the file exists):

     $text = new OpenDocumentText($fullpath);
     // doing nothing here
     $text->close();

I also tried to hack the flag ZipArchive::CREATE inside the
file OpenDocumentText.php.

The ODT file is quite complex (an invoice). May
there be any elements in there that opendocumentphp
cannot process yet and therefore breaks?

Thanks!

Erik

[ODP-dev] ODF - Calc

[Andreas N. <ane...@az...>]

Hi folx,

i hope, that there are some more developers out=20
there, because there was long time no traffic on this list.
I just want to let you know, that i did some work on my Calc-Export Class.
I know that you're going another, more javalike,=20
way to implement the ODF Stuff, but maybe my code=20
has some features to help this project. I'll attach the file to this mail.

Here the last changes:

- The class now can create multiple worksheets=20
via bOOoCloseSheet() and bOOoNewSheet().
- There is now a cellcounter=20
sOOoGetCurrentCell(), that gives you the=20
Coordinates of the last written cell ( e.g. A3 or C6 ), this is important=
 for:
- One can now write formulas the the sheet, via bOOoWriteFormula().

So you can make now Spreadsheets with PHP-Data and pre-defined Calculations.

hope that this helps

Andreas

Andreas 'Nupela Didiman' Neugebauer

----------
EDV - Leiter                    Tel:  +49 421 59 08 166
Azul Kaffee GmbH & Co. KG       Fax:  +49 421 59 08 108
Am Deich 43                     Mobil:+49 177 38 85 486
D - 28199 Bremen                SKYPE: aneugebauer

----------
B=FCro:  ane...@az...      Privat: and...@ew...

----------
Quam quisque norit artem, in hac se exerceat !


















AZUL KAFFEE GmbH & Co. KG
Am Deich 43
D-28199 Bremen
Tel.: +49 (0)421 59 08 0
Fax: +49 (0)421 59 08 200
Mail: in...@az...
http://www.azul.de
----------------------------------------------------------------------------------------------------
Kommanditgesellschaft, AG Bremen HRA 14059
pers=F6nlich haftender Gesellschafter: W.Wille

AZUL KAFFEE GmbH Bremen
AG Bremen HRB 4324

Gesch=E4ftsf=FChrer: Dr. Helmut Reining

USt.-Identnummer: DE 114 617 193
Steuernummer: 73 505 22306 / =D6sterreich 993/7027

Re: [ODP-dev] Why I think $root_path is evel --- was: Using $root_path.

[Alex L. <ad...@ya...>]

no...@se... wrote:
> Hi folks,
>
> I've got a strong dislike for the committed pathing fix by Alex and I want
> to disargee the need of such a global variable like $root_path.
>
> As fas as I can see there is no need for a global variable in a library
> such as OpenDocumentPHP anyway.
>
> Let think of the following scenarios:
>
> a) You are root of you webserver and have total control:
>
> You can put OpenDocumentPHP where ever you want and can add the Path to
> the classpath either by put it in the php.ini or adding it with a propper
> set_ini statement.
>
> b) You are nor root neither have total control:
>
> In this case you can ask your administrator to add it to the php
> classpath, which he/she probably don't. You can try  to add it with a
> propper set_ini statement, which will probably won't work. Or, and this
> will allways work, you put the directory OpenDocumentPHP/ in the same
> directory (as a subdirectory) as you application. Because your application
> is in the classpath, the require_once statement will find the
> OpenDocumentPHP stuff anyway.
>
> Planed before 0.6.0 is also a PEAR package, so you can install
> OpenDocumenPHP as simple as:
>
>   
>> pear discover-channel pear.opendocumentphp.org
>> pear install opendocumentphp/OpenDocumentPHP
>>     
>
> In this case OpenDocumentPHP will be in your PEAR directory and this
> should work for end users and developers.
>
> But why is a global variable, like Alex did it, such a bad thing, you may
> ask?
>
> The answers is easy: It is not OOP and you, as a library developer, don't
> know if an other application needs exactly this variable for something
> different.
>
> If I am (totally) wrong, please stand up and tell me what I am miss!
>
> 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
>   
I agree Norman, this is a hack. This is a problem that 90% of web
applications have to deal with. If you want to use OpenDocumentPHP as a
library to build other applications and this is what it is designed for
then I agree that the global variable is not the correct usage, however
in my eyes the best path for OpenDocumentPHP is not just as a library,
but it should be used with both an input and output module with the
current SVN copy being used only an a process between the two.

At the current moment we take input from a web-page, or from where-ever
so that it meets a set Interface. This then gets processed and turned in
a OpenDocument file, .odt for example.

In my opinion this is great, but it could be better. What is stopping us
from being able to accept .odt files as inputs and then producing a
web-page as an output. To me this offers the most flexibility and the
best usage of OpenDocumentPHP.

As for $root_path, if you wish this to purely be a library for
developers to pick up and develop with then that's great, in its current
form it does it's job, but even if it only for my benefit we need to
clarify the exact direction of the project. Is it as a PEAR library or
as an input, process, output application?

Thanks, Alex.

[ODP-dev] Why I think $root_path is evel --- was: Using $root_path.

[<no...@se...>]

Hi folks,

I've got a strong dislike for the committed pathing fix by Alex and I want
to disargee the need of such a global variable like $root_path.

As fas as I can see there is no need for a global variable in a library
such as OpenDocumentPHP anyway.

Let think of the following scenarios:

a) You are root of you webserver and have total control:

You can put OpenDocumentPHP where ever you want and can add the Path to
the classpath either by put it in the php.ini or adding it with a propper
set_ini statement.

b) You are nor root neither have total control:

In this case you can ask your administrator to add it to the php
classpath, which he/she probably don't. You can try  to add it with a
propper set_ini statement, which will probably won't work. Or, and this
will allways work, you put the directory OpenDocumentPHP/ in the same
directory (as a subdirectory) as you application. Because your application
is in the classpath, the require_once statement will find the
OpenDocumentPHP stuff anyway.

Planed before 0.6.0 is also a PEAR package, so you can install
OpenDocumenPHP as simple as:

> pear discover-channel pear.opendocumentphp.org
> pear install opendocumentphp/OpenDocumentPHP

In this case OpenDocumentPHP will be in your PEAR directory and this
should work for end users and developers.

But why is a global variable, like Alex did it, such a bad thing, you may
ask?

The answers is easy: It is not OOP and you, as a library developer, don't
know if an other application needs exactly this variable for something
different.

If I am (totally) wrong, please stand up and tell me what I am miss!

Yours,
Norman

[ODP-dev] Using $root_path.

[Alex L. <ad...@ya...>]

Howdy guys,

Just committed the pathing fix, at the current moment to run 
OpenDocumentPHP the directory is it contained in must be within the ini 
files classpath, as a result this makes it annoying to use, as a work 
around please include the $root_path when including a new file, when 
starting a new test case please define $root_path to set it to the root 
of the /src directory.

So, if I have...

OpendocumentPHP
    src
       OpenDocumentPHP
          >> This is where the ODPHP Code is.
       Samples
          >> This is where the test cases are.
    doc

When defining a text case in the Samples directory please note that you 
should define the variable $root_path to point back to the src directory...
    $root_path = './../';

So that when this is called in the line to get the OpenDocumentText class..
    require_once $root_path . 'OpenDocumentPHP/OpenDocumentText.php';

the string becomes.. './../OpenDocumentPHP/OpenDocumentText.php', and 
therefore can be found from the Samples directory..

Enjoy.. Alex.

[ODP-dev] Waiting for Phing 2.3.0 ...

[<no...@se...>]

Hi folks,

I ame desperately waiting for the next Phing release (2.3.0 or 2.2.1 what
ever published next). Until than you have to patch the old 2.2.0 release
to work together with the current PHPUnit 3.0.X release or try the SVN
release which makes you need a new build.xml file.

I my local development environment I currently use the SVN build of Phing
with a new build.xml and trying to setup the new phase1nt directory
structure. This realy is a major step forward, but without a shipped Phing
2.3.0 it is to hard to maintain both (a release working with 2.2.0 and one
with 2.3.0/svn). So I will put on this as soon as Phing 2.3.0 is
published.

If you have setup a running Phing direct from the SVN, you can ask me by
private mail to get a copy from phase1nt tree.

Yours,
Norman Markgraf

Re: [ODP-dev] A good place to start

[<no...@se...>]

Hi Dan et al,

the problem is the current directory structure. The source code is in the
src/ directory and all source code references are made with a base
directory './src' in mind. The problem is now, that if you run
OpenDocumentPHP as a library you will have your own program as code base
and the OpenDocumentPHP stuff in your classpath. So you have the separate
your own source code from the OpenDocumentPHP source code.
For instance, you will include the PEAR stuff always with something like
'require_once "Phing/PhingFile.php";' or 'require_once
"PHPUnit/PHPUnit_TestSuite.php";'.

If you take a look at the published files on sourceforge.net you will find
two packages. One is call OpenDocumentPHP-0.5.1-src.zip, which is a more
or less a snapshot of the subvision repository at a certain time. But
there is also a file named OpenDocumentPHP-0.5.1.zip, which  is what we
call the 'production code'. It is only the library (and the api
documentation done by PhpDocumentor) and that is what people need, if they
only what to use our code. If you take a look at that part of the code you
will see, that there is a directory OpenDocumentPHP which includes all our
production code and that all the line like "require_once
'meta/DublinCoreFragment.php';" are substituted by something like
"require_once 'OpenDocumentPHP/meta/DublinCoreFragement.php';".

The new directroy structure will end this messy situation, by putting all
the code in src/OpenDocumentPHP/ which should go as OpenDocumentPHP/ in
the library and all other code (like the samples, tools etc) in the
src/samples/, src/tools/ ... directories.

So if you develop an example for OpenDocumentPHP you should use the
production or new directory structure to include the classes, thinking
that OpenDocumentPHP was lnked by the user in there classpath.

May be I should write a simple sample first.  ;-)

So, Dan, your are complete right, when you want to use

> require_once('OpenDocumentPHP/OpenDocument.php');

and

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

because you added OpenDocumentPHP first, even when there is (currently) no
such suffix in the require_once statements in the source code.

> 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).

As you can (not ?) see, I love such things as "Agile Development" or "XP".
The problem is, that I spend most of the time in coding then follow the
rules of XP or AD, shame on me! But if you use a project not only to
finish something, but to learn more and get benefit not you by getting it
done but also by see how your own vision changes ... well too much
dreaming I think...


> 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.
That would be nice.

> Are we running production code with superglobals turned on or off?
No superglobals please. Always thing of a hyper secure system, that allows
nearly nothing! ;)

Yours,

Norman

PS: Dan, you have now SVN access, too.

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
>

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

[<no...@se...>]

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

Re: [ODP-dev] RFC: A new directory structure for OpenDocumentPHP

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

Norman et al:
Sorry for the several day delay on my response.

> - 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?

> - 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.

> - 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 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?

I realize some of these questions are rather simple but I want to make
absolutely certain I understand the basics before wreaking havoc :-)

Regards,
Dan


On 2/16/07, no...@se... <no...@se...> wrote:
>
> Dear Dan, and hi to all other developers too,
>
> Daniel Longest wrote:
>
> > Norman:
> > What would be a suitable place to break myself into the project? I
> understand the overarching purpose of OpenDocument and what we
> specifically are trying to accomplish but I lack experience in
> development of this nature.  I am looking forward to contributing (and
> learning along the way), but I don't know the best place to begin
> >
> > Regards,
> > Dan
>
> your question about suitable places to break into the project is not so
> easy to be answered. Let me see what we need:
>
>
> - the possibility to add math formula (as text or as chart formula) is
> another good point to start. Maybe something with MathML...
>
> - Last but not least: Refaktoring! Refaktoring!  Refaktoring!
>
> I hope I could help a little. More about this next week.
>
> Yours,
>
> Norman
>
> BTW: Currently only Alex, Andreas and me do have write access to the svn!
> Are there any others who wants to join us?
>
>
> -------------------------------------------------------------------------
> 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
>

Re: [ODP-dev] RFC: A new directory structure for OpenDocumentPHP

[<no...@se...>]

Dear Dan, and hi to all other developers too,

Daniel Longest wrote:

> Norman:
> What would be a suitable place to break myself into the project? I
understand the overarching purpose of OpenDocument and what we
specifically are trying to accomplish but I lack experience in
development of this nature.  I am looking forward to contributing (and
learning along the way), but I don't know the best place to begin
>
> Regards,
> Dan

your question about suitable places to break into the project is not so
easy to be answered. Let me see what we need:

- 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.

- the manifest class has some missing functionality, which should be
'easiely' added by some one...

- an extension to add thumbnails (or something like thumbnails) to the
od-archive  would be nice, but seems not so important.

- 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.

- the possibility to add math formula (as text or as chart formula) is
another good point to start. Maybe something with MathML...

- Last but not least: Refaktoring! Refaktoring!  Refaktoring!

I hope I could help a little. More about this next week.

Yours,

Norman

BTW: Currently only Alex, Andreas and me do have write access to the svn!
Are there any others who wants to join us?