Re: Implementing "attributre dependencies"

You are welcome!

I am glad facing that you try hard to develop the mainly maintained by=20
yourself, unstable trunk release. But this is it all about. Is Scarab=20
dead? No, it is definitely not, but, e.g. for us and for the moment,=20
following Scarab on tigris.org, does not make any sense...

Let's say we are still keep on working on b22 release branch internally,=20
for our release. There is a memoComp featured version of b22, but for=20
the reasons above, and there is still our personal time, I cannot say if=20
we will ever be back on trunk...

cheers,
jhoech

Am 27.08.2011 12:20, schrieb hussayn dabbous:
> My current plan with Scarab:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> There is one big issue remaining for me to do (right now): We want to add
> data dependencies, so that the value of one attribute can drive the value=
 of
> another attribute.
>
> For example:
> dependancy between "tool" (drop down list) and "admin" (drop down list):
> When the "tool" value is changed , then the  "admin" value changes
> automatically according to the defined dependency.
>
> * one to one dependencies (that's what we need right now) should not be
> a big deal.
>      "A particular tool has exactly one responsible admin"
>
> * 1 to n dependencies should be automatically supported: Changing one
> value can
>     change a set of other attributes values, we only need to define
> multiple dependencies
>     between attributes. One particular case could be:
>
>     Dependency: Primary responsibility. from "tool" to "admin"
>     Dependency: Secondary responsibility: from "tool" to "admin"
>
>     This will probably be implemented, except i find unexpected problems.
>
> * n to one dependencies
>      That sounds a bit related to constraints. Maybe there is a simple
> solution,
>      i might take a look into that (but probably only when i need it).
>
> * n to m dependencies seem out of focus to me as i think that the
> complexity
>     of the definition would blow up significantly.
>     I do not want to implement that. However it may be possible that
>     combining "one to n" and "n to one" could(...) be a way to go, but it
>     realy sounds like "better keep hands off that" ...
>
> Ok, maybe the better solution is "complex attributes" ?
> So i can for example define an attribute named "tool" with "sub attribute=
s":
>
> tool.long name
> tool.shortname
> tool.primary_admin
> tool.secondary_admin
> tool.development state
>
> I like that idea although i fear that complex attributes may need even
> more changes
> to the Scarab code base than adding dependencies...
>
> Feedback, advice, hints are welcome.
>
> best regards,
> hussayn
>
> ------------------------------------------------------
> http://scarab.tigris.org/ds/viewMessage.do?dsForumId=3D456&dsMessageId=3D=
2831103
>
> To unsubscribe from this discussion, e-mail: [[email protected]=
gris.org].
>

--=20

Johannes H=C3=B6chst=C3=A4dter
www.memocomp.de

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=3D456&dsMessageId=3D28=
78852

To unsubscribe from this discussion, e-mail: [[email protected]=
is.org].