Hints for AODL

Hi, Lino,

That's a very nice thing, that you add many features. In our
company we
also use this library for generating both ods and odt
documents, but our
team's very small, so we make almost none improvements.

Basically, the whole community works by collaborating in the
mailling
list. If you have nice features, you post patches against
the trunk. You
could send patches as an attachments, and not as in-line
text in an
email, this way it would be easier for the committers to
integrate them.

When you have posted enough (which is a non obvious
number
) patches,
and project leaders think you are a good person, they grant
you commit
access, and you need no longer to submit patches.

All the major ideas should be discussed in the mailing list,
so that
participants might discuss them. In most cases, if you need
some
feature, you can add it freely, as long as the
implementation is
correct, and as long as it does not go out of project
scope.



You can also read a very nice book by Karl Fogel about how
to run
successfull open source project. You can buy or download it
here:
http://hammett
.castleproject.org/?p=33


p.s. i'm sending a copy of this mail also to the mailing
list,

> I'm making a lots of improvements to this library (I
need it to work and it must work well and very fast)
> Actually I added the date, boolean, N/D values
handling.
> I fixed some wrong "styles" behaviour.
> 
> It seems that the project is still in an early stage
> (and I'm making my "local copy" growing in
functions..)
> I would like not to begin a different project (a fork)
but I'd like to enhance the main project to contribute.
> 
> What should I do?
> Should I mail the changing details to someone who
approves them and possibly checks-in the files?
> 
> Please tell me how do you actually do the community
development.
> I think I have a lot to give to this project (and to
the community)

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

OK guys
So..
Here's the first patch (more to come)

This is a very important fix because without it the
performace are badly
affected
(I have a lot of identical styles and this consumes a lot of
memory and
processing cycles)

You'll find attached cell.cs and two sample files (one made
before changes
on the style handling and one after)
The patch I did for CellStyle should be applied to every
other <oblect>Style
(to make the things work as they should)
I'll work on that but I actually prefer to ehnance other
pieces of code.

Let me know what do you think about that.

Attached you'll find also Table.cs and Row.cs this files
have some minor
fixes (you can analyze them yourself).


BTW:
Is there a reason why the StyleName property exist?
Why can't you simply use <object>.Style.Name?

Possible answers:

1) Because setting the StyleName property handles the XML
modifications
needed to persist the info
My answer: this can be easily done even with getter-setter
for the style
object.

2) Because you may need to specify a StyleName without
having a Style (for
example to make it external)
My asnwer: so define an "ExternalStyle object"
whose constructor has the
"stylename param" and use this.object.style = new
ExternalStyle("ExtStyleName");


In both cases the StyleName property should be bropped to
make things more
intuitive for developer:
"If you want to set the style for an object then create
an appropriate
IStyle (compatible with the object) and assign it to the
object's style
property."


Waiting for your answers.

Bye,
Lino

-----Messaggio originale-----
Da: Darius Damalakas [mailto:darius.damalakasgmail.com] 
Inviato: venerd́ 13 luglio 2007 9.14
A: Lino Barreca
Cc: devodftoolkit.openoffice.org
Oggetto: [odftk-dev] Re: R: [odftk-dev] Hints for AODL

[...]

If you have nice features, you post patches against the
trunk. You
could send patches as an attachments, and not as in-line
text in an
email, this way it would be easier for the committers to
integrate them.

When you have posted enough (which is a non obvious
number
) patches,
and project leaders think you are a good person, they grant
you commit
access, and you need no longer to submit patches.
[...]

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org