Edgewall Software
Modify

Opened 12 years ago

Last modified 4 years ago

#3911 new enhancement

implement an object system (xwiki, roundup)

Reported by: anonymous Owned by:
Priority: normal Milestone: next-major-releases
Component: general Version: 0.10
Severity: major Keywords: tracobject xref
Cc: hw@… Branch:
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 (20)

comment:1 by Christian Boos, 12 years ago

Keywords: tracobject added
Milestone: 2.0
Owner: changed from Jonas Borgström to Christian Boos
Severity: normalmajor

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 by Christian Boos, 12 years ago

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 by anonymous, 12 years ago

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

comment:4 by Christian Boos, 12 years ago

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 by anonymous, 12 years ago

Summary: implement xwiki's object systemimplement 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 by anonymous, 12 years ago

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

comment:7 by Christian Boos, 12 years ago

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 by ittayd@…, 12 years ago

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

in reply to:  7 comment:9 by ilias@…, 12 years ago

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

in reply to:  8 comment:10 by ilias@…, 12 years ago

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 by ittayd@…, 12 years ago

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!

in reply to:  11 comment:12 by Christian Boos, 12 years ago

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:15 by ittayd@…, 12 years ago

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 by ittayd@…, 12 years ago

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 by anonymous, 12 years ago

Cc: hw@… added

comment:18 by Christian Boos, 9 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:19 by Christian Boos, 9 years ago

Milestone: triagingnext-major-0.1X

See also related #533, for the query side.

comment:20 by Ryan J Ollos, 4 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.