When you click the remove link in a report for OneToManyComponent, the
element is removed from the report but is still in the memory. Here are
steps to reproduce :
Open : http://localhost:8080/seaside/examplebrowser
Click Edit
In 'Phone numbers' click Add
Put values inside fields and Save
Give a first name and a last name
Save the form
Remove the phone number
Click Edit
In 'Phone numbers' click Add
Put values inside fields and Save
The two phone numbers are displayed even if we removed one.
Hi,
due to the increasing demand to have a central Magritte and Pier code
repository, I migrated all my existing version to a new squeak-source
repository at http://mc.lukas-renggli.ch. All the development will
now go trough this interface.
URLs to load the latest version of Magritte and Pier should still be
working, however if you had a password to commit code into those
directories it won't work anymore. Please register an account and I
will add you to the appropriate projects.
http://mc.lukas-renggli.ch/magrittehttp://mc.lukas-renggli.ch/pier
I also created two projects for add-ons to Magritte and Pier, that
are ment as places to put small-extensions you want to put into
public, such as a new description type for Magritte or a new widget
for Pier. Those two repositories have got public write rights.
http://mc.lukas-renggli.ch/magritteaddonshttp://mc.lukas-renggli.ch/pieraddons
If you have your own projects that you would like to share, feel free
to register your own project.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
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