MABlockToCondition
by Damien Cassou
Hi,
I don't understand why there is #isZero, #beginsWith:, #isNil and the
others coded in MABlockToCondition. If I understand well, this method
are not needed due to the #doesNotUnderstand: method which does exactly
the same thing.
Bye
--
Damien Cassou
CSS3 : "On passe au HSL, plus intuitif et moins orienté CRT que le
RGB. Il y a du HSLA". Et en plus, ça veut dire quelque chose (au moins
pour l'auteur) !
17 years, 7 months
[Pier] How to enable safety
by tgkuo
Hi,
I'm running a Seaside/Pier web site. Overall, the wiki/kernel
framework is cool, as I knew, it can support security and had object
storage solution, thanks to added-on Krypon/Magma packages, but for
the time being in current versions, I can not find the way to disable
the edit function in the frontpages, i.e. anyone can edit my pages
without the need to log in.
I noticed that the edit function was disable as default in old
versions but it is open now. It might be a silly question, but how to
re-enable the log-in as default?
TIA
tkkuo
17 years, 7 months
Re: Magritte
by Lukas Renggli
> "A framework for describing the types held by domain classes. This includes
> describing both basic units (like Booleans, numbers, and strings) and
> contents of collections. The framework also allows describing tolerated
> values in individual variables."
Yes, and also some basic relationship between described objects (has
to be improved as well).
For now I didn't add anything to Magritte that I didn't require in one
of my own projects. There are a couple of productive applications
using Magritte, as you can see in the slides. Obviously there are gaps
that need to be filled by other developers and their particular needs,
so this is really an open project that anybody can contribute.
> Thank you for being willing to add me as a developer. Please note that I
> will not submit any changes before you have agreed to them. If I look at
> doing any changes, it will be the ones I described in my last e-mail.
I've added you as developer to the "Magritte" (the core framework) and
"Magritte Add-Ons" (for small add-ons) project, so you can directly
publish there. If you want to keep your package in your own repository
you might want to create a new project and only commit the
fixes/modification that need to go into the core to the other
repositories.
Actually I don't mind if you publish your changes into "Magritte":
from time to time I will review them, maybe discuss with you and
eventually merge them into my image. The official versions known to be
usable are always on SqueakMap, anybody that is directly using code
from my repositories knows about the fact that it might be broken,
incompatible, change, etc.
> Which version of Squeak would you recommend using for Magritte?
I am currently working with Squeak 3.8. If you prefer 3.7 or 3.9
should be fine too. There are some tests that break in some versions
of Squeak, but this is not really a big deal.
Locking forward seeing your commits ;-)
Btw, there is a mailing-list at
<http://www.iam.unibe.ch/mailman/listinfo/smallwiki>, that might be a
good place to further discuss about Magritte, etc.
Lukas
On 2/16/06, Runar Jordahl <runar.jordahl(a)gmail.com> wrote:
>
>
> Thank you for your answer.
>
>
>
> I think the current version of Magritte sums up to:
>
>
>
> "A framework for describing the types held by domain classes. This includes
> describing both basic units (like Booleans, numbers, and strings) and
> contents of collections. The framework also allows describing tolerated
> values in individual variables."
>
>
>
> From the presentation, I think Magritte is well-designed for doing this
> task. ElementDesc forms the superclass for these descriptions. Looking at
> the diagrams, it is easy to understand the design and how it is to be used.
> In my mind, this should not be changed. The core should probably not be
> messed up by introducing new information (like privately owned etc.) just
> because one developer has this need. I think if such a philosophy were
> followed, you would quickly see your well-designed classes cluttered. The
> core (ElementDesc) should stay like it is: "A system for describing types".
>
>
>
> Thank you for being willing to add me as a developer. Please note that I
> will not submit any changes before you have agreed to them. If I look at
> doing any changes, it will be the ones I described in my last e-mail.
>
>
> Which version of Squeak would you recommend using for Magritte?
>
> Kind regards
> Runar Jordahl
--
Lukas Renggli
http://www.lukas-renggli.ch
17 years, 7 months
Re: Magritte
by Lukas Renggli
> Thinking more about this, I would actually go for a :-) It would be nice if
> other developers could use your framework to make *any* description they
> like, without needing to modify the core framework. Below I outline how it
> could be done:
>
> [snip]
Ok, I understand. a might be a good approach indeed, if you actually
want to modify existing behavior/visitors. By dispatching trough your
owner-ship hierarchy this will be easily possible without the need to
modify the core. I only thought about adding an extra attribute as a
class-extension, but now I understand that you need to modify existing
functionality as well ... ;-)
> I would not expect that the core framework would need many modifications in
> order to get this working. The added value would be large. Other developers
> could simply subclass Description, and use these.
If you think the ownership (or something else that is missing) should
go into the core, you can directly modify the framework and submit to
my repository. If you register at <http://mc.lukas-renggli.ch>, I will
add you as a developer to the Magritte project.
Cheers,
Lukas
On 2/15/06, Runar Jordahl <runar.jordahl(a)gmail.com> wrote:
> Thank you for your answer. Please read my comments below.
>
>
> On 2/14/06, Lukas Renggli <renggli(a)gmail.com> wrote:
> > > a - Subclass ElementDesc and add a Ownership hierarchy.
> > >
> > > b - Add some new property on RelationDesc to store type of ownership.
> >
> > I would go for b, as I don't see a reason why to introduce a new
> > Ownership hierarchy.
>
>
> Thinking more about this, I would actually go for a :-) It would be nice if
> other developers could use your framework to make *any* description they
> like, without needing to modify the core framework. Below I outline how it
> could be done:
>
>
> Page 24 of
> http://www.lukas-renggli.ch/seaside/annecy/Magritte.pdf
> shows how Container has many "children" of type ElementDesc. Now, this leads
> me to think (or hope) that Magritte can create a Description being type
> "Container" for a single method (Accessor).
>
> Below I give an example of how a description for phone numbers could be
> marked being private using a new description class named
> MAOwnershipDescription. (Note that this class could have been added outside
> the core framework.)
>
> RunarPersonModel class>>descriptionPhoneNumbers
> ^(MAOneToManyRelationDescription auto: 'phoneNumbers'
> label: 'P. Numbers')
> classes: (Array with: RunarPhoneNumber);
> default: Array new;
> yourself) ,
> (RunarOwnershipDescription isPrivate: true)
>
> Just like "ZeroDivide , RangeError" creates an ExceptionSet (at least in
> VisualWorks), the message #, in the statement above will create a Container
> having two children. If this was used, developers could combine various
> descriptors for a *single* property. They could mix the descriptions in the
> core framework with their own, specialized descriptions.
>
> Accessing the descriptions will need specialised methods to get only one (or
> a set of) types. This is similar to how handling exceptions is done. An
> example could be accessing all ElementDesc (and subclasses), and sending
> #validate to them:
>
> aDescption on: ElementDesc do: [:anElementDesc | anElementDes validate]
>
> I would not expect that the core framework would need many modifications in
> order to get this working. The added value would be large. Other developers
> could simply subclass Description, and use these.
>
>
> Kind regards
>
> Runar Jordahl
>
--
Lukas Renggli
http://www.lukas-renggli.ch
17 years, 7 months
Re: Magritte
by Lukas Renggli
> 1 - Does Magritte allow describing how objects relate to each other in terms
> of ownership? For example, an address might be "privately owned" by a
> person, and a method is "privately owned" by a class. On the other hand, a
> person might "refer" to a birth country, but does not own this country.
No, there is no such metaphor (yet). It probably comes closest to the
property #persistent with the two states #bePersistent and
#beEphemeral.
> a - Subclass ElementDesc and add a Ownership hierarchy.
>
> b - Add some new property on RelationDesc to store type of ownership.
I would go for b, as I don't see a reason why to introduce a new
Ownership hierarchy.
> 2 - I notice that extra support has been added to build GUIs and Seaside web
> pages. Will this code be separated in they own packages, so that it is
> possible to only load the "core" Magritte framework into an image? Then,
> making new support code (for example building Pollock forms) should be
> easier, as one can follow the pattern in your support code, and no
> modification to the core Magritte is needed.
Yes, this is already the case. You can load Magritte-Core and you just
get the model. Loading Magritte-Seaside loads the Seaside support,
loading Magritte-Morphic loads the Morphic support, loading
Magritte-Tests loads the tests, etc. The repository with all packages
is available at: <http://mc.lukas-renggli.ch/magritte.html>.
> 3 - Do you have any plans for porting the framework to VisualWorks?
> Good luck with your work! It would be nice if you could make one single
> framework that can be used for automatic GUI building, domain object
> validation, relational persistency framework, web services, and other
> systems requiring description of the domain.
I was asked about a VisualWorks version already several times. Some
time ago I adapted the exporter that Seaside is using to Magritte and
Pier. Moreover while writing the code I payed attention not to use
Squeak specific features, unfortunately there are a few problems that
are not that simple to solve (#initialize and streams).
With the help of the tests it should be possible to do a complete port
in one day, however I can't do it myself: Magritte and Pier are
basically a single-man project and I don't have the time to
concentrate on other things beside my master-thesis right now.
Contributors are of course welcome in all areas (porting, extending,
testing, documentation, ...)!
Thanks for your comments,
Lukas
On 2/14/06, Runar Jordahl <runar.jordahl(a)gmail.com> wrote:
>
>
> I read about Magritte at
> <http://www.lukas-renggli.ch/seaside/annecy/Magritte.pdf>
> and have a few questions, which I would be thankful if you could answer.
>
> 1 - Does Magritte allow describing how objects relate to each other in terms
> of ownership? For example, an address might be "privately owned" by a
> person, and a method is "privately owned" by a class. On the other hand, a
> person might "refer" to a birth country, but does not own this country.
>
> In order to make such a description, I can see two solutions:
>
> a - Subclass ElementDesc and add a Ownership hierarchy.
>
> b - Add some new property on RelationDesc to store type of ownership.
>
> I ask, as describing such relationship between objects can be helpful when
> copying them (where to stop copying), deciding where a version field should
> be located (at the top object), and when deleting from a relational database
> (delete recursively all "privately owned" objects).
>
> I remember TopLink had such a property in its descriptor.
>
> 2 - I notice that extra support has been added to build GUIs and Seaside web
> pages. Will this code be separated in they own packages, so that it is
> possible to only load the "core" Magritte framework into an image? Then,
> making new support code (for example building Pollock forms) should be
> easier, as one can follow the pattern in your support code, and no
> modification to the core Magritte is needed.
>
> 3 - Do you have any plans for porting the framework to VisualWorks?
> Good luck with your work! It would be nice if you could make one single
> framework that can be used for automatic GUI building, domain object
> validation, relational persistency framework, web services, and other
> systems requiring description of the domain.
>
> Kind regards
> Runar Jordahl
--
Lukas Renggli
http://www.lukas-renggli.ch
17 years, 7 months
description translation
by Cédrick Béler
Is it easy to associate different language for description - (to
automatically translate a UI ?)
It's mainly all a question of String translation, maybe we can use the
message translated ... but where to store the different values ...
Is it feasible ?
Cheers
Cédrick
17 years, 7 months
Re: Pier Search Component
by Lukas Renggli
Hi Chad,
> Search functionality is key to the cms project I am working on.
> However, the search component in Pier seems to be broken for me. I
> get this error:
the search of Pier is very sophisticated, probably much more than
anybody wants. It is more like a query engine and supports its own
(strange) syntax that you obviously don't follow (therefor the strange
error, sorry) ;-)
See PRQueryTests to see some examples:
" finds pages with a table "
self kind = 'Table'
" finds pages with external links to iam.unibe.ch "
(self kind = 'External Link') & (self url matches: 'iam.unibe.ch')
To do a full text-search as you like, you might want to use the short
form like, but you need the quotes to make the parser happy:
'foo'
I see that many people struggle with that (powerful) search engine. It
is very easy to come up with something much simpler, it is just a
matter of adding a new visitor class and to implement a few simple
methods to, if I remember this is described in our paper. I will come
up with a simple solution this weekend and send you a notification, if
time allows.
Cheers,
Lukas
> SmaCCParserError: Token not expected
>
> * MARelationParser(SmaCCParser)>>reportErrorMessage:
>
> self a MARelationParser
> temps
> aString 'Token not expected'
> inst vars
> scanner a MARelationScanner
> currentToken {(5,4,#(30))}
> errorToken {(5,4,#(30))}
> stateStack an OrderedCollection(1 13)
> nodeStack an OrderedCollection(#test)
>
> * MARelationParser(SmaCCParser)>>reportError:
>
> self a MARelationParser
> temps
> anInteger 0
> inst vars
> scanner a MARelationScanner
> currentToken {(5,4,#(30))}
> errorToken {(5,4,#(30))}
> stateStack an OrderedCollection(1 13)
> nodeStack an OrderedCollection(#test)
>
> * MARelationParser(SmaCCParser)>>handleError:
>
> self a MARelationParser
> temps
> anInteger 0
> inst vars
> scanner a MARelationScanner
> currentToken {(5,4,#(30))}
> errorToken {(5,4,#(30))}
> stateStack an OrderedCollection(1 13)
> nodeStack an OrderedCollection(#test)
>
> * MARelationParser(SmaCCParser)>>performParsingLoop
>
> self a MARelationParser
> temps
> action 0
> actionType 3
> inst vars
> scanner a MARelationScanner
> currentToken {(5,4,#(30))}
> errorToken {(5,4,#(30))}
> stateStack an OrderedCollection(1 13)
> nodeStack an OrderedCollection(#test)
>
> * MARelationParser(SmaCCParser)>>parse
>
> self a MARelationParser
> temps
> inst vars
> scanner a MARelationScanner
> currentToken {(5,4,#(30))}
> errorToken {(5,4,#(30))}
> stateStack an OrderedCollection(1 13)
> nodeStack an OrderedCollection(#test)
>
> Is there an easy fix for this?
>
> Thanks,
>
> Chad
>
--
Lukas Renggli
http://www.lukas-renggli.ch
17 years, 7 months
[Smallwiki] SmallWiki Mailing List
by Lukas Renggli
Sorry to annoy you with a test-mail. There were problems with the
list lately and some mails got lost, so I have to check if it is
properly working again. Moreover we switched from Majordomo to
Mailman, so it is really worth a first test ;-)
Remember, even-tough this list is called "SmallWiki" this is the
place to ask questions and to discuss about:
SmallWiki [SW]
Pier [PR]
Magritte [MA]
Have fun,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
17 years, 7 months
