implement an object system (xwiki, roundup)

[anonymous]

in xwiki, i can define objects (set of properties) and then have pages to create new objects, and displaying them, and of course, querying them. this is a great way of structuring documents. e.g., i can create a FAQ object with 'question' and 'answer' fields, then form a page that shows all questions and then all items.

[cboos]

Yes, this is something that I find quite interesting and potentially very useful.

TWiki also has similar concepts (Structured Wiki), and there's also WikiD which might be inspiring.

Trac just recently got PageTemplates and a proposal for a more flexible data model. The TracCrossReferences idea was also about getting more benefits from the implicit structure already present in Trac.

Eventually, all of this could lead to a much more powerful Trac...

[cboos]

#4278 was marked as duplicate.

I think the TracDev/Proposals/DataModel addresses the flexibility required by this feature. There's still the dynamic schema part and the xref part that needs to be refined.

[anonymous]

what about using roundup (roundup.sf.net)? it is also written in python.

[cboos]

Yes! Why do we bother with Trac, as there's Roundup!!! + it has even be selected by Python as its official BTS !

no I'm not bitter about it, just joking :)

[anonymous]

roundup is a light weight orm framework, on top of which there's an issue tracker

trac is much more: it (should) aims to be a total solution for managing software projects - documentation, issue tracker, roadmap, scm integration. and it is based on a wiki engine for that.

my suggestion is to use roundup as a library inside of trac. this will add many usefull things to trac. the reverse, making roundup into a full solution, is much more difficult (which is why i don't use roundup and am trying to push features into trac)

[anonymous]

to make things clearer: by suggesting to use roundup, i suggest to use its orm tier, not the bug tracker.

[cboos]

Well understood, thanks for the clarification ;)

However, I think having an ORM or not is not really what matters here. Having a flexible object data model is. Making use of an ORM can be done before (i.e. mapping the current data model) or after (mapping the new model), it doesn't really play a role, I think.

Plus, if we'd use an ORM, we'll probably pick SqlAlchemy.

I'll probably soon start a branch to experiment with the new ideas exposed in the data model proposal, see googlegroups:trac-dev:8cf3f5fe0e476ce5

[ittayd@…]

I want to try and see if I can somehow do it myself (though skeptical because of lack of time)

Can you please point the way in these issues: - where is wiki formatting processed? - where are tickets created

[ilias@…]

Replying to cboos:

Well understood, thanks for the clarification ;) However, I think having an ORM or not is not really what matters here. Having a flexible object data model is. Making use of an ORM can be done before (i.e. mapping the current data model) or after (mapping the new model), it doesn't really play a role, I think.

It plays a major role.

having an ORM which is OO and supports inheritance is a fundamental part of this work (estimated 80% of the work)

some notes subjecting ORM's: http://case.lazaridis.com/wiki/Persist

Plus, if we'd use an ORM, we'll probably pick SqlAlchemy.

SQLAlchemy without an decent OO layer (which is currently missing) is worthless for an OO design.

possibly you should evaluate that one of roundup.

I'll probably soon start a branch to experiment with the new ideas exposed in the data model proposal, see googlegroups:trac-dev:8cf3f5fe0e476ce5

I've commented on this:

http://groups.google.com/group/trac-dev/msg/7fa629d7b72fe74b

[ilias@…]

Replying to ittayd@qlusters.com:

I want to try and see if I can somehow do it myself (though skeptical because of lack of time) Can you please point the way in these issues: - where is wiki formatting processed? - where are tickets created

This is a complex task, but if you really want to start it, please let me know. You may want to synchronize your efforts with this plan:

http://dev.lazaridis.com/base/milestone/wiki-rework

http://dev.lazaridis.com/base/roadmap

[ittayd@…]

i hope this is not turning into a flamewar...

my choice of words was wrong i guess. ORM usually means mapping the DB tables to objects that can be manipulated like any other objects. however, the more or less a 1-1 relationship is kept between objects and tables (a property maps to a column).

so indeed there are 3 tiers: trac -> dynamic model -> ORM where the dynamic model uses objects like ModelObject? (or whatever) to create dynamic objects. the ORM can then help manipulate the ModelObject?.

anyway, an ORM can still be used if it can dynamically manage new classes. then, you read a class definition from a file, create a class object, let the ORM tool analyze it, create an appropriate table in the db, and voila!

[cboos]

i hope this is not turning into a flamewar...

Sure not, I wonder what makes you believe that ;)

I think you're a step ahead. My approach is the following. First, we should refactor the current data model so that things are done in a more consistent way. That's already a big task.

Then, we can maybe think about creating new classes dynamically. RoundUp does it by reading class definition from a Python source file (eek), other Wikis XWiki XWiki], TWiki) do it with template pages, etc.

I think the Trac Way^TM for doing that would eventually be a snappy WebAdmin module ;)

an ORM can still be used if it can dynamically manage new classes

I think SqlAlchemy is very flexible in the way the mapping can be done. Please see this overview and then the Data Mapping section and also the Advanced Data Mapping.

While this is quite powerful, I don't want to mix everything. I'd first like to find the proper balance for the generic model, then eventually use SqlAlchemy to clean up the code further.

[ittayd@…]

see also http://wiki.ontoworld.org/index.php/Semantic_MediaWiki

[ittayd@…]

or this: http://base.kendra.org.uk/

[ittayd@…]

also, see http://en.wikipedia.org/wiki/RDFa. using RDFa is nice because then the raw wiki text can be processed by rdfa tools

[ittayd@…]

also, the rdfa constructs may be kept in the html rendering as is.

i think to implement this, the parser needs to be redesigned to be more open. either provide new tokens for parsing, or, two phase parsing of first building a DOM of the document so plugins can scan it, or, both.

or, create macros that do the same, but with '[' instead of '<'