I think I will be interested in specific descriptions and before trying
to code them or whatever else, here are what I need... Mostly here to
discuss on solutions to do that without "breaking" Magritte ;)
- will it be good to have something like a nested descriptions
(MANestedContainer ??). I have to represent event and according to the
type of event (human or natural), the option list is different. How to
you do that ? using a nesting container (that doesn't exist yet) or
using two descriptions with maybe a MADynamic object for the second
description linked to the first one...
- second point, I will probably need to represent a "physical"
measurement (with a unit or an intensity). Units or descriptions of
intensity can be different according to what is measured. So here, what
would you do ? using nested description ? What about creating a
MAMeasurementDescription but if so, will it be a subclass of
MAElementDescription and then MAMagnitudeDescription or will it be a
subclass of MAContainer or even of MADescription ?
Thanks
Cédrick
Just an email to make some remarks... maybe useless, so if I say
something stupid tell it ;)
First, I found the name of Pier really good. It really reflects that it
is more than a wiki (for me the wiki is just a component among
others...). Pier is a framework where you can attach and organize
seaside application (component)...
so I was wandering Lukas if you plan to make a specific component to
organize the application Layout. It is done now in the environnement
edit... so with a wiki syntax... and maybe it's possible to create a
specific component for it that could be organized dynamically with ajax
like in the google personnalized main page
(http://cdrick.free.fr/googlePersonalized.png /I was moving the "RSS
component" Musiciens.biz during the capture/)...
Do you think it is possible, interesting ? I wish I could create such a
component but I actually have some doubt :d
Anyway Thanks for all this great work (especially magritte for me ;) )
See you
Cédrick
Hi all,
I modified the MAOneToManyComponent>>add method not to accept the
duplicated :
MAOneToManyComponent>>add
[...]
(result notNil and: [(self value includes: result) not])
ifTrue: [ self value: (self value copyWith: result); refresh ].
Bye
Good enough, appreciate the explanation.
> -----Original Message-----
> From: owner-smallwiki(a)iam.unibe.ch
> [mailto:owner-smallwiki@iam.unibe.ch] On Behalf Of Lukas Renggli
> Sent: Tuesday, December 06, 2005 2:42 AM
> To: smallwiki(a)iam.unibe.ch
> Subject: Re: Autofocus
>
> > Anyone know what happened to autofocus on magritte descriptions?
> > With this gone, how are you currently putting the cursor in
> the first
> > field when an edit form appears?
>
> I removed it.
>
> The problem was basically because there is no good place to
> put this property and the following problems:
>
> - you could have multiple descriptions within the same form
> where auto-focus was set to true, especially when composing
> descriptions at runtime from several different sources.
>
> - #autofocus: did not work with some more complex
> form-elements like one-to-one, one-to-many, multiple-selection, ...
>
> - when changing from WAHtmlRenderer to WACanvasRenderer there
> was no replacement for the method #autofocus:, however this
> could be easily added again.
>
> - I felt that is unnecessary to have #autofocus: in the
> description itself, if you really need to automatically focus
> an element you probably do a sophisticated manual rendering anyway.
>
> - proper separation of view and meta-model, something
> Stéphane Ducasse and I just recently discussed: a problem in
> the current version of Magritte is that I mix meta-stuff and
> Seaside/Morphic configuration, such as #componentClass:,
> #attributes, #morphicClass,
> #autofocus: ... this should be the responsibility of a
> different object, not the description itself. It leads to
> some hard to tackle problems with extension-methods, if you
> want to use descriptions with/ without different
> view-implementations, however it is not easy to solve. Maybe
> something for Magritte 1.1 ;-)
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>
>
> It is definitely not a conversion method, the resulting
> description is completely independent from the receiver of
> the message: it can be recomposed, reused with or without any
> other model instance. What is more, have you ever seen an
> #asClass conversion method to ask your instance for its
> meta-representation (#class)?
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
Hmm.. that's a good point. My inclination is to toss the word meta in
there somewhere, it is after all metadata, but you already said you were
avoiding that. It's not that big a deal I guess, I just wanted to raise
the issue since it was a problem for me. I still think description is
far to useful an accessor in "any" problem domain to use it as an
extension on Object, I'd at least call it descriptor, but I'm not
complaining. I love the framework man, keep up the great work, I check
for updates daily and have learned quite a bit about Smalltalk style
from reading your code.
Hi samir
I think that this is important that people willing to continue to
work on SmallWiki 1 takes control of it.
So this is good that you invest and shared.
Stef
> Hi,
>
> I put a stable version of smallwiki1 on squeaksource
> (http://www.squeaksource.com/smallwiki1 , SmallWiki-Kernel-stable and
> SmallWiki-Parser-stable). This version is currently used for
> squeak.org, and www.seaside.st, and seems stable as a rock ! The
> current version, available in squeakmap, will be renamed unstable. So
> for little and/or trivial features, just put them into the stable
> version on squeaksource (read/write access for everyone), and for big
> and important features, requiring some deep modification of the
> smallwiki1 kernel, probably shoud we work with the unstable branch
> (read/write access for everyone too).
>
> Let's share our contributions !
>
> Regards,
> Samir
Thanks a lot Samir!! This is really helpful.
On 12/2/05, Samir Saidani <saidani(a)squeakfr.org> wrote:
> Hi,
>
> I put a stable version of smallwiki1 on squeaksource
> (http://www.squeaksource.com/smallwiki1 , SmallWiki-Kernel-stable and
> SmallWiki-Parser-stable). This version is currently used for
> squeak.org, and www.seaside.st, and seems stable as a rock ! The
> current version, available in squeakmap, will be renamed unstable. So
> for little and/or trivial features, just put them into the stable
> version on squeaksource (read/write access for everyone), and for big
> and important features, requiring some deep modification of the
> smallwiki1 kernel, probably shoud we work with the unstable branch
> (read/write access for everyone too).
>
> Let's share our contributions !
>
> Regards,
> Samir
> _______________________________________________
> Webteam mailing list
> Webteam(a)lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam
>
--
Jason Rogers
"I am crucified with Christ: nevertheless I live; yet not I,
but Christ liveth in me: and the life which I now live in
the flesh I live by the faith of the Son of God, who loved
me, and gave himself for me."
Galatians 2:20
Hi,
Does anyone know what is happening with the Smallwiki on kilana?
Doru
Begin forwarded message:
> From: Niklaus Haldimann <nhaldimann(a)gmx.ch>
> Date: December 3, 2005 2:10:30 PM GMT+01:00
> To: ESE Staff <ese-staff(a)iam.unibe.ch>
> Subject: [Fwd: SmallWiki]
> Reply-To: ese-staff(a)iam.unibe.ch
>
> SmallWiki has been down for quite some time, where should we complain?
>
> Nik
>
> -------- Original Message --------
> Subject: SmallWiki
> Date: Sat, 3 Dec 2005 13:40:38 +0100 (CET)
> From: Michael Pfeuti <m_pfeuti(a)yahoo.de>
> To: Nick Haldimann <nhaldimann(a)gmx.ch>
>
> nur zur information. das smallwiki vom ESE05
> funktioniert nicht mehr. es gibt immer einem timeout.
>
> mfg michael pfeuti
>
> *******************
> Michael Pfeuti
> Unteres Eichholz 22
> CH-3425 Koppigen
>
> +41344131860
> +41797068821
> *******************
>
>
>
>
>
>
> ___________________________________________________________
> Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
> anmelden: http://mail.yahoo.de
>
>
--
Tudor Adrian Girba Software Composition Group
(www.iam.unibe.ch/~girba) University of Bern, Switzerland
"Beauty is where we see it."
> >Honestly, maybe it's a culture difference, but damned if I
> don't have a
> >description accessor on tons of my domain objects, summary
> doesn't feel
> >right to me. I was just thinking something that's less common than
> >description, that's just so generic a term and so common for an
> >accessor. Even something similar that is more behavioral
> sounding like
> >descriptor, or, really, a conversion method like asDescrition or
> >asDescriptor rather than just description. It's not really
> an accessor
> >anyhow, it's building a description of the object and
> returning it as a
> >container, so a conversion method seems reasonable. Thoughts?
> >
> >
> How about #descriptions which is a common naming for
> collections of anything ?
I would even prefer that, since I don't see myself as having collisions
with it, but I really do feel it should be a conversion method. When
you want a component, you say anObject asComponent, when you want a
description, why not anObject asDescription? The description isn't a
property of the object, it's a different representation of it, a meta
representation.
>
> Do you have a better suggestion on how to name it?
>
> I was looking for a word that does not include 'meta' as a
> substring (I think it is already used too often in different
> contexts) and that reads well and tells what it is used for.
> #description was the best thing I could find.
>
> In real live I only observed once having an accessor that was
> called #description and then I could change that together
> with the author to be something like #summary. I think every
> method extension sooner or later conflicts with existing software.
>
> Another thing, probably out-of-topic in this thread, is how
> you should call accessors, if you have an object referencing
> an external description, such as MAValidationError. I simply
> called it #description, even-tough this description does not
> describe the receiver. I probably should have called it
> #actualDescription or #targetDescription or
> #externalDescription or ... I was too lazy at the moment.
> However this problem stays the same, even if I replace the
> #description-prefix with any other.
Honestly, maybe it's a culture difference, but damned if I don't have a
description accessor on tons of my domain objects, summary doesn't feel
right to me. I was just thinking something that's less common than
description, that's just so generic a term and so common for an
accessor. Even something similar that is more behavioral sounding like
descriptor, or, really, a conversion method like asDescrition or
asDescriptor rather than just description. It's not really an accessor
anyhow, it's building a description of the object and returning it as a
container, so a conversion method seems reasonable. Thoughts?
