Edgewall Software
Modify

Opened 8 years ago

Last modified 4 years ago

#3911 new enhancement

implement an object system (xwiki, roundup)

Reported by: anonymous Owned by: cboos
Priority: normal Milestone: next-major-releases
Component: general Version: 0.10
Severity: major Keywords: tracobject xref
Cc: hw@…
Release Notes:
API Changes:

Description

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.

Attachments (0)

Change History (19)

comment:1 Changed 8 years ago by cboos

  • Keywords tracobject added
  • Milestone set to 2.0
  • Owner changed from jonas to cboos
  • Severity changed from normal to major

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…

comment:2 Changed 7 years ago by cboos

  • Keywords xref added

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

comment:3 Changed 7 years ago by anonymous

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

comment:4 Changed 7 years ago by 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 :)

comment:5 Changed 7 years ago by anonymous

  • Summary changed from implement xwiki's object system to implement an object system (xwiki, roundup)

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)

comment:6 Changed 7 years ago by anonymous

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

comment:7 follow-up: Changed 7 years ago by 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

comment:8 follow-up: Changed 7 years ago by 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

comment:9 in reply to: ↑ 7 Changed 7 years ago by 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

comment:10 in reply to: ↑ 8 Changed 7 years ago by 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

comment:11 follow-up: Changed 7 years ago by 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!

comment:12 in reply to: ↑ 11 Changed 7 years ago by 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 WayTM 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.

comment:14 Changed 7 years ago by ittayd@…

comment:15 Changed 7 years ago by 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

comment:16 Changed 7 years ago by 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 '<'

comment:17 Changed 7 years ago by anonymous

  • Cc hw@… added

comment:18 Changed 4 years ago by cboos

  • Milestone changed from 2.0 to unscheduled

Milestone 2.0 deleted

comment:19 Changed 4 years ago by cboos

  • Milestone changed from triaging to next-major-0.1X

See also related #533, for the query side.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new The owner will remain cboos.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from cboos to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.