Re: Sitegroup issue!

Jukka Zitting wrote:
> Hi,
> 
> On 3/7/06, Tarjei Huse <tarjei-y/[email protected]> wrote:
>>> The create() case is a lot easier as there is no chance of breaking
>>> existing objects (nothing can link to an unexisting object).
>> Well, that does not work today so no code uses that method :-)
> 
> :-) Good point. Perhaps we should fix that instead of thinking about
> setsitegroup()?
> 
>> Wrt to sitegroup management, I can see a lot of good uses for
>> setsitegroup() - I think we need functionality like it, at least until
>> we get proper acls in core.
> 
> I'm not sure I follow you. The only use case I see for setsitegroup()
> is as a part of a low-level shoot-yourself-in-the-foot administration
> interface.
It is vital in sitegroup and host creation. As I said, doing the 
mgd_auth_midgard dance makes for much more ugly code that is far harder 
to get right and maintain.

Wrt to ACLs, the point is that sitegroups are used as a kind of 
accesscontroll - some time in the future maybe ACLs can replace them.

>> My main issue at the moment is getting a release of Midgard where the
>> API is stable, consistent and working. Do you have any input on how we
>> can achieve that?
> 
> I mentioned some points already in the Midgard core quality thread
> started by Torben. The main point IMO is that we need a more
> structured development approach that starts with *specifying* the API
> we're using. The current approach of writing code and tweaking is a
> sure way to end up with an unstable, inconsistent, and non-working API
> (trust me, I wrote large parts of the legacy Midgard code :-). Even
> good practices like unit testing or documentation are of little use if
> the underlying API keeps changing along the way.
> 
> There is also another way to achieve the same goals... That's the
> pragmatist way of accepting the underlying stuff as given and building
> an abstraction layer that hides the inconsistencies and works around
> the known issues. This is what Torben has been doing amazingly well,
> and I'm quite convinced that MidCOM is the one reason why Midgard
> still is a viable CMS alternative. But as witnessed by Torben's recent
> frustration, this way can only take you so far. Sooner or later you
> need to focus on the fundamentals.

> IMO the recent discussions on MidgardConfig and MidgardConnection as
> well as some of the previous design discussions have been a good sign,
> but so far we've failed to take the process further. I'd like to see
> the development process extended into something like this:
> 
>     a) Discuss the design of a feature
>     b) Document the feature based on the achieved consensus
>     c) Write unit tests based on the documentation
>     d) Implement the feature so that it matches the documentation and
> passes the unit tests
Ok, so what you are saying is that for all the outstanding items for 1.8 
this process should be followed?

Another and major point here is that many of the problems we are seeing 
are in the legacy code. How should we clean up those?

> So far the order of these steps has been more like: d, b, a, c. No
> wonder we're having trouble. :-)
Yep. We have been dropping b and c some times as well for good measure.

Tarjei


> BR,
> 
> Jukka Zitting
> 
> --
> Yukatan - http://yukatan.fi/ - [email protected]
> Software craftsmanship, JCR consulting, and Java development