Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
DB Table merge
I’d like to see the DB tables txp_page, txp_form, and txp_css merged in to a single table with more extensible fields than just name and text. This is mostly a brainstorm post and I’d like to get feedback from other txp coders. This is an idea I’ve been letting brew for quite some time and will most likely implement anyway, but I’d like it to be a more community friendly feature set.
The new table would store a text element that is matched to a name and information about type/encoding. This would allow for plugin authors to easily extend the type of text data that can be stored and delivered without adding additional tables. E.g. In addition to all pages, forms and css stored in a table, an author could also add javascript, xml files or base64 encoded plugin preferences.
Table: txp_text
Fields:
name varchar(64) — friendly name for stored form
type varchar(32) — friendly type name. E.g. css, article-form, page, etc.
version int — I’d really like to have an online version history
encoding varchar(64) — a mime type or type specific encoding identifier. E.g. application/xml, text/javascript, base64_serialized, etc.
data text — the text data
unique( name, type , version)
This change is guaranteed to break a few plugins, but it would allow the txp core to provide a lot of useful functionality. By having this available from the core, plugin authors would be required to write less code, simplify installations (fewer extra tables) and benefit from automatic bug fixes. The core could also provide a basic display class for managing typed lists, version histories, version diffs and edit forms. Special edit forms, like the css editor would be an extension to the display class.
PS i realize this is not exactly the most coherent post, so ask questions here or in the IRC channel (it’s lonely in there).
PPS if some one says, “why not just use the form table?”, I just might fork the code :P
Offline
Re: DB Table merge
Manfre wrote:
The core could also provide a basic display class for managing typed lists, […] edit forms.
A few pointers to – as I think – similar efforts in the crockery branch:
Me pointing there serves mainly as a touchstone of whether my understanding of your intentions is correct. Please advise.
Offline
Re: DB Table merge
Robert, you’re on track. My thoughts on the display code are based upon those crockery classes.
Offline
Re: DB Table merge
So, then we would need a databinding layer for those base views, as the current way of clutching cells to fields is clumsy. Slim, not “CakePHP – The Second Coming”.
When this has arrived (contributions welcome!), the underlying database structure is IMHO merely a matter of taste, be it either object type specific or as generic with a “type” field as you propose – in OO talk: “Inherit” vs. “Extend”. So your idea might have benefits, or it might be totally invisible to plugin authors once the views and controllers are abstract enough. Depends.
Offline
Re: DB Table merge
I agree that the classes are clumsy. I spent some time learning them by porting mem_moderation to an element. What is the current end goal for the controller classes? How extensible are they intended to be? When do you envision an interface freeze on the classes for 4.1?
Has crockery gotten to a point where the head is installable? Last I checked it (over a month ago) it had many serious issues. I needed to get stuff done, so I stayed with the 4.0.x code. Also, if you can point me to a feature list for 4.1, I’d be happy to chip away at it. If crockery has an open ended list, I’m going to stick with hacking 4.0.x until there is a defined release condition for 4.1.x. I already deal with too many vague/arbitrary releases 9-5 and I prefer to avoid it for my hobby.
Offline
Re: DB Table merge
Manfre wrote:
When do you envision an interface freeze on the classes for 4.1?
Not in the near future. They are at a state where the first descendent classes and consumers are coded, so the base classes evolve as common patterns arise among their children. “Agile development”, as they euphemistically like to call it – no waterfall process.
Has crockery gotten to a point where the head is installable?
It is installable, though I never had any serious problems earlier, so YMMV.
I already deal with too many vague/arbitrary releases 9-5 and I prefer to avoid it for my hobby.
Then, honestly, avoid crockery. It’s a target for contributors with a potentially long-term or intense commitment and an inclination to experiments.
Offline
Re: DB Table merge
is this ‘feature list’ still relevant? http://textpattern.com/wishlist
also what is considered experimenting? seems like its been in experimental stage for the past two years :P
Offline
Re: DB Table merge
iblastoff wrote:
is this ‘feature list’ still relevant? http://textpattern.com/wishlist
Definitely.
also what is considered experimenting?
From my POV, you shouldn’t be frustrated if the code or concepts you contributed are turned upside down once or twice and you had to redo parts of it again as development progresses. While it won’t happen regularly, chances are bigger than in a mature branch.
Offline
Re: DB Table merge
wet wrote:
Then, honestly, avoid crockery. It’s a target for contributors with a potentially long-term or intense commitment and an inclination to experiments.
I have no issues with how you define crockery. I submitted the original file upload support 4-5 times to dean because of how volatile svn was at the time. All I really wanted to know is if there was a public list of intended features/changes that would need to be finished before the devs said “poof 4.1”. I was unaware of the wishlist, which gives me some idea of where to direct my efforts and what I can expect to change between now and the beta.
Before seeing the wishlist, crockery’s svn log and a few sporadic mentions throughout this forum were the only reference to 4.1’s direction.
Offline
Re: DB Table merge
Manfre wrote:
I was unaware of the wishlist, which gives me some idea of where to direct my efforts and what I can expect to change between now and the beta.
Before seeing the wishlist, crockery’s svn log and a few sporadic mentions throughout this forum were the only reference to 4.1’s direction.
i assume it would be rather hard to gather would-be submitters of patches if they don’t know where/how to contribute. i think even some minor updates via the developer weblog (which is nearing 3 months without a word) would be largely beneficial to everyone.
to be honest i have no clue how i even came upon the wishlist. i had it bookmarked for some reason. even when i use the textpattern site search tool nothing comes up and it doesnt seem to be officially linked anywhere on the main site. perhaps it should?
Last edited by iblastoff (2007-09-20 23:27:47)
Offline
#11 2007-09-29 11:25:12
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: DB Table merge
and please update this
Offline
Re: DB Table merge
I feel like the whole topic of transparency of development priorities get’s periodically rehashed over and over again with no satisfactory outcomes. Users are frustrated. Devs get a bit defensive and no one is terribly happy.
I D E A
A simple, publicly viewable checklist with a mechanism for accepting suggestions, viewing progress and encouraging input from everyone. Activecolab or something similar could handle it pretty well. I imagine it could work like this.
- There’d be a list of new capabilities/bugs/issues organized by several levels of priority admin’d by core devs (actually I’d be willing to donate time to do the organizational and administrative grunt work here…)
- Anyone could submit new suggestions for features and other non-devs could provide feedback on those features/items to show if there is a demand for these items
- You could include a simple rating mechanism to determine an idea’s popularity and gage demand.
- Core devs would decide whether the idea is worthy of inclusion and what priority level it deserves, and why.
- Each item can accept a list of non core dev contributors
- Contributors could publicly “accept” an item and communicate with devs about how they can help and who might already be working on related stuff.
- When an item is complete it gets a checkmark, when it’s in active dev it gets an in-progress designation when no-one has signed on it gets an “unclaimed” designation.
- Progress is totally visual, end-users can see the process and progress and frustrations are minimized
Theres a lot of underutilized talent around TXP; dev, designer and otherwise. I think this approach would organize and speed development, invest more people in TXP and alleviate frustrations without sacrificing dev oversight and core control.
Thoughts?
Last edited by mrdale (2007-09-29 16:04:19)
Offline