Glen Ezkovich wrote:
On Dec 7, 2004, at 4:18 AM, Daniel Fagerstrom wrote:
Refactoring JXTG ================
I think everything starts here. Once this gets refactored the opportunities for further development should become apparent. There is nothing terribly wrong with JXTG, except that it is a monolithic class with monolithic methods.
Yes, my current view is that I feel unconfortable with starting from scratch (http://www.joelonsoftware.com/printerFriendly/articles/fog0000000348.html). Fun or not, we should just build a large test set arround JXTG and refactor it, towards the kind of architecture that we have discussed in previous discussions.
We can do that work on a copy of JXTG in the template block. There is not that much activity on the current codebase, so I think it easier to keep them syncronized than working on everything whithin core. I have started some work in that direction and will put them in SVN as soon as I get my splitted version of JXTG to compile again :/
For 1), the back compabillity preserving refactoring of JXTG. I cannot see any need for voting about this. Either it gains community support in terms of that people joins in design, implementation and testing, or it don't. And in that case we just remove it. Then if the new refactored implementation should replace the current one and get "oficial status", thats certainly something to vote about. Also if we develop some new interfaces e.g. for ELs or formaters that we feel that should be made part of core, it will also be something that should be handled by proposals and votes.
I can assure you that I have no urge to implement everything myself at all (as some of you might have noticed I enjoy design descussions and proposals more than implementing stuff ;) ),
You mean some people actually LIKE to implement stuff? ;-)
I do, but not as much as discussing the design ;)
I will continue to strive for community involvment. And I will write a proposal about how to continue the refactoring as soon as I find time.
Next Generation JXTG ====================
This is about how we should continue our development of the template language beyond JXTG 1.0. It is purely at the RT stage, no concrete design proposals yet. Later there might be proposals in form of documents or proof of concept implementations. But that is a later question.
And an interesting discussion. I think once people look at the refactored JXTG and have an itch to scratch you will see a few attempts at expression language development.
Yes, the current monolith makes that far to hard.
Attribute Driven Templating ===========================
This is ongoing discussions. My hope is that we can design the template engine in such a way that the synatx handling part is plugable so that attribute and tag driven templates (JXTG) can coexist, (although not in the same document ;) ).
I'm guessing that after refactoring JXTG you will see that this is easily doable. I'm only guessing because I have only taken a brief look at JXTG's code, but one of the goals of refactoring is to organize the code properly.
Yes, it will be easily doable after refactoring.
But that is a technical quiestion IMO. Anyway, we need to discuss the consequences of dirrerent syntaxes a little bit more before implementing anything.
You mean defining the language. No one wants to implement. ;-)
Actually there are some people around here that prefer programming to discussing. And a few impresive persons who manage to be active in both areas :)
Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow
Cool, one of my favourite books.
