Sitegroup issue!

Jukka Zitting wrote:
> Hi,
> 
> Responding in here to Tarjei's comment about
setsitegroup():
> 
> On 3/7/06, Tarjei Huse <tarjeinu.no> wrote:
>> Torben Nehmer wrote:
>>> The short version: API consistency and Ease of
Use.
>> I agree with torben. For the same reason, I would
also like to have the
>> simple object->sitegroup usage instead of todays
setsitegroup().
> 
> The problem with
> 
>     $object = ...;
>     $object->sitegroup = ...;
>     $object->update();
> 
> is that it is conceptually very much different from
> 
>     $object = ...;
>     $object->someproperty = ...;
>     $object->update();
> 
> Normal property updates are simple to handle because
they only affect
> the object in question. The sitegroup change however
affects not only
> the object in question but also all parameters,
attachments, child
> objects, and any objects that have a link to or from
the object in
> question.
> 
> If we limit the update() method to just change the
sitegroup of a
> single object, then we essentially allow update() to
break database
> consistency. But if we allow update() to cascade the
sitegroup change,
> the method becomes much more complex than before. Such
use also makes
> update() access controls more complex as they'd then
need to take the
> sitegroup administration rights into account as well.
The sitegroup
> property (or in fact any of the metadata properties)
does *not* behave
> like a normal property.
Isn't this something you can say for most update operations
that work on 
links?

> To summarize, such a sitegroup update feature might be
easy to use but
> it certainly wouldn't help API consistency. Just
imagine writing a
> test case or API document that takes all the special
cases (e.g.
> should a parent link be cleared when changing the
sitegroup!) into
> account.

I can see your point.

Is it possible for php to define some properties as read
only - so that 
you at least can get a notice when trying to set the
sitegroup?

Also, the most important thing now is to decide on one
method and 
implement it.

Tarjei



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


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/7/06, Tarjei Huse <tarjeinu.no> wrote:
> Isn't this something you can say for most update
operations that work on
> links?

No. When you update a normal link property, the underlying
database
will remain consistent (well, it would if Midgard did check
link
constraints). There is also no way that an update of an
object could
cause links in *other* objects to break. But if you change
the
sitegroup of an object, then all the links that point to
that object
will suddenly break.

This is just one of the tricky issues that a setsitegroup()
method
needs to solve somehow. In fact I'd prefer not supporting
sitegroup
changes at all, if an object needs to be migrated from one
sitegroup
to another, couldn't it just be copied just like you'd do
when
migrating content from one database to another.

> Is it possible for php to define some properties as
read only - so that
> you at least can get a notice when trying to set the
sitegroup?

It would be possible if we defined the generic Zend getter
and setter
methods instead of copying property values back and forth
from
MgdSchema object properties to PHP object properties...

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

Jukka Zitting wrote:
> Hi,
> 
> On 3/7/06, Tarjei Huse <tarjeinu.no> wrote:
>> Isn't this something you can say for most update
operations that work on
>> links?
> 
> No. When you update a normal link property, the
underlying database
> will remain consistent (well, it would if Midgard did
check link
> constraints). There is also no way that an update of an
object could
> cause links in *other* objects to break. But if you
change the
> sitegroup of an object, then all the links that point
to that object
> will suddenly break.
> 
> This is just one of the tricky issues that a
setsitegroup() method
> needs to solve somehow. In fact I'd prefer not
supporting sitegroup
> changes at all, if an object needs to be migrated from
one sitegroup
> to another, couldn't it just be copied just like
you'd do when
> migrating content from one database to another.
This is partly a chicken and egg problem. I need this to
create 
sitegroups and hosts. Having a setsitegroup operation is a
lot better 
than debugging strange errors in mgd_auth_midgard().


>> Is it possible for php to define some properties as
read only - so that
>> you at least can get a notice when trying to set
the sitegroup?
> 
> It would be possible if we defined the generic Zend
getter and setter
> methods instead of copying property values back and
forth from
> MgdSchema object properties to PHP object properties...

I guess that would imply $obj->get('att') ?
Tarjei

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


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/7/06, Tarjei Huse <tarjeinu.no> wrote:
> This is partly a chicken and egg problem. I need this
to create
> sitegroups and hosts. Having a setsitegroup operation
is a lot better
> than debugging strange errors in mgd_auth_midgard().

Ah, your use case is different from the general update(). Do
you mean
something like this:

    $object = new someobject();
    $object->sitegroup = $sitegroup;
    $object->create();

The create() case is a lot easier as there is no chance of
breaking
existing objects (nothing can link to an unexisting object).

> > It would be possible if we defined the generic
Zend getter and setter
> > methods instead of copying property values back
and forth from
> > MgdSchema object properties to PHP object
properties...
>
> I guess that would imply $obj->get('att') ?

Not necessarily. Zend allows the registration of special
handle_overload_{get,set} handlers for internal classes. See
the PHP4
overload extension (http://
www.php.net/manual/en/ref.overload.php) for
an idea of how this works.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

Jukka Zitting wrote:
> Hi,
> 
> On 3/7/06, Tarjei Huse <tarjeinu.no> wrote:
>> This is partly a chicken and egg problem. I need
this to create
>> sitegroups and hosts. Having a setsitegroup
operation is a lot better
>> than debugging strange errors in
mgd_auth_midgard().
> 
> Ah, your use case is different from the general
update(). Do you mean
> something like this:
> 
>     $object = new someobject();
>     $object->sitegroup = $sitegroup;
>     $object->create();
> 
> 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


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.

If the ->sitegroup attribute is hard to manage, then I
suggest we remove 
it from 1.8 and instead get a setsitegroup() method that
works. As an 
added bonus, this is BC as well.

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?

Tarjei

>>> It would be possible if we defined the generic
Zend getter and setter
>>> methods instead of copying property values back
and forth from
>>> MgdSchema object properties to PHP object
properties...
>> I guess that would imply $obj->get('att') ?
> 
> Not necessarily. Zend allows the registration of
special
> handle_overload_{get,set} handlers for internal
classes. See the PHP4
> overload extension (http://
www.php.net/manual/en/ref.overload.php) for
> an idea of how this works.
> 
> BR,
> 
> Jukka Zitting
> 
> --
> Yukatan - http://yukatan.fi/ - infoyukatan.fi
> Software craftsmanship, JCR consulting, and Java
development


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

> Hi,

Hi,

>> Is it possible for php to define some properties as
read only - so that
>> you at least can get a notice when trying to set
the sitegroup?
>
> It would be possible if we defined the generic Zend
getter and setter
> methods instead of copying property values back and
forth from
> MgdSchema object properties to PHP object properties...

I can not agree here.

1. Zend setter and getter would be still generic one.
2. Zend1 has no support for read only properties.
3. You can not make one setter and getter for Zend1 and
Zend2.
4. Zend2 is not primary aim *right now* to provide another
setter and getter
functionality.
5. I do not trust resource handler used for object instances
( but I will trust one day ;)
6. Code like:

if($obj->prop)
    echo $obj->prop;

$obj->prop = $vale;
echo $obj->prop;
$obj->update();

will trigger 4 additional resource lookups.

7. Coming back to resource handler. Show me how many basic
php extension uses
resources for external objects and how many of them uses
more than 500 resource
handler per request. midgard-java extension is an exception
but I do not think it's
widely used.

8. As long as we really do not need this I can not spend
much time to debug php leaks.
This is resource handler or generic array issue IMO.

So as long we use Zend1 and Zend2 property setter and getter
is not good thing IMO.

Piotras



------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

>> Ah, your use case is different from the general
update(). Do you mean
>> something like this:
>>
>>     $object = new someobject();
>>     $object->sitegroup = $sitegroup;
>>     $object->create();
>>
>> The create() case is a lot easier as there is no
chance of breaking
>> existing objects (nothing can link to an unexisting
object).

Sitewizard creates SG0 groups members and later changes its
sitegroup.
Kill me but I do not remember all details right now.

> Well, that does not work today so no code uses that
method 

But can work tomorrow 

> 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.
>
> If the ->sitegroup attribute is hard to manage, then
I suggest we remove
> it from 1.8 and instead get a setsitegroup() method
that works. As an
> added bonus, this is BC as well.

We could move sitegroup (gu)id to metadata object.

Piotras



------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/7/06, Tarjei Huse <tarjeinu.no> 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.

> 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

So far the order of these steps has been more like: d, b, a,
c. No
wonder we're having trouble. 

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

> Hi,

Hi,

>> Well, that does not work today so no code uses that
method 
>
> 
Good point. Perhaps we should fix that instead of thinking
about
> setsitegroup()?

As I wrote I will fix this soon , but you still break
sitewizard by
dropping this functionality.

> (trust me, I wrote large parts of the legacy Midgard
code .

My man! Do you know that I miss docs for legacy API for at
least a year? ;)

>     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
>
> So far the order of these steps has been more like: d,
b, a, c. No
> wonder we're having trouble. 

Yep , but there are plenty of things which have been done
like this
and not like that because of legacy API or for some other
reasons.
And I do not want and can not discuss it.

Piotras


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Jukka Zitting wrote:
> Hi,
> 
> On 3/7/06, Tarjei Huse <tarjeinu.no> 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/ - infoyukatan.fi
> Software craftsmanship, JCR consulting, and Java
development


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org