smallwiki April 2010

smallwiki@list.inf.unibe.ch

18 participants
45 discussions

by Norbert Hartl

I decided for the time being to use the pier user management and rights management for my application. If I use these it seems to be feasible to use the commands as well. Do you think it is a good idea to extend the usage of PRCommands into my own (embedded) components (that do not deal with the pier structure)? And if you think it is what are the ways of having commands that deal with an embedded component? I mean commands are resolved over the couple context-structure. If I have a component embedded inside of this structure how can make a command act on this embedded component? thanks, Norbert

14 years, 8 months

Re: Re[2]: [Esug-list] GLORP & Magritte integration/refactoring

by Maarten MOSTERT

Yes of cours if it is done correctly many things can be extended. But in that case it might be Margritte that will suffer from an important API change. Maybe they won' agree on that. Is it not to difficult to keep everybody happy ? @+Maarten, ----- Original Message ----- From: "Юрий Мироненко" <tallman(a)inbox.ru> To: "ESUG Mailing list" <esug-list(a)lists.esug.org> Sent: Tuesday, April 20, 2010 12:26 AM Subject: Re[2]: [Esug-list] GLORP & Magritte integration/refactoring > >> I would however prefer that you don't change Glorp's API as might be your >> intention. > > As Niall told some day before, nothing prevent from supporting current API > via new methods, it's even some kind of additional test. > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/listinfo/esug-list > >

14 years, 8 months

Re: [Esug-list] GLORP & Magritte integration/refactoring

by Maarten MOSTERT

Dear Mirko, I really appreciate your project however to be honest and allthough my websites runs a Pier one click image, I never really understood what Margriite really is. As a very happy Glorp user (945 calls to glorpSession) I would however prefer that you don't change Glorp's API as might be your intention. I pretty much would prefer you to follow the official branch. What I really would like to see however (but this is obviously another subject) is the Glorp documentation to be hosted on a Pier / Margritte image. This will give us way more possibilities to improve and help it's adoption. @+Maarten, ----- Original Message ----- From: "Mirko Kiefer" <mirko.kiefer(a)arcor.de> To: "ESUG Mailing list" <esug-list(a)lists.esug.org> Sent: Monday, April 19, 2010 12:15 PM Subject: Re: [Esug-list] GLORP & Magritte integration/refactoring Of course the link to the project description would be useful ;) http://gsoc2010.esug.org/projects/glorp%20&%20magritte%20integration/refact… On Apr 19, 2010, at 12:07 PM, Mirko Kiefer wrote: > Hi all, > I submitted a proposal for the GSoC project "GLORP & Magritte integration/refactoring" and would greatly appreciate if some Mentors could review it. > GLORP and Magritte are both really exciting frameworks that can solve problems thousands of developers are hassling with. I believe that especially in web-applications there is a huge potential to make life easier for many developers if such frameworks would become more accessible and better promoted. > The project I want to work on aims at integrating Magritte which allows automatic generating of user interfaces with GLORP which is a great framework for storing your objects into a relational database. The plan is to integrate and separate the common parts of both and simplify the way you use both frameworks. > There is an interesting conversation on the ESUG mailing (starting at 2010-03-10) list that led to the idea of this project - especially the comments of Alan Knight and Niall Ross were quite insightful to me. > At the end of the project there will be an integrated and refactored codeset and a sample application demonstrating the ease of use of the integrated frameworks. > If we are then able to promote these frameworks in an adequate way combined with what we have with Seaside I see a great opportunity to attract more developers to the Smalltalk community. > Look at what led to the great popularity of a language like Ruby - it was not only the language itself, it was frameworks like Ruby on Rails which greatly simplified the development of web applications including straightforward mapping to a database. Well, I believe a combination of Seaside, GLORP and Magritte can make these tasks even easier. The problem is that these frameworks are hard to get into initially and that people only realize how great they are once they spent some time actually using them. > The project I want to work on is one step in reducing this barrier and I plan to continue it even after GSoC, especially in terms of writing tutorials and usage examples. > So hope you can afford a bit of time to review the project and give me feedback and advise. > > Thanks, > Mirko_______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/listinfo/esug-list _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/listinfo/esug-list

14 years, 8 months

utf-8 encoded URL path info?

by Norbert Hartl

I just recently discovered that actual browsers are displaying utf-8 safe url encodet URL paths as the right characters. Meaning http://en.wikipedia.org/wiki/Gew%C3%BCrztraminer actually displays http://en.wikipedia.org/wiki/Gewürztraminer As far as I can see in pier the URL path is tightly coupled to the name of a structure. And structure names are restricted to only a few characters. The comments in the code reason this for safe usage in some object protocols. What would be the way to go if I want to enable those types of URLs? What are the problematic cases if a structure name could consist of non-7bit characters? thanks, Norbert

14 years, 8 months

Migration of pier tree

by Norbert Hartl

It seems I used quite some old pier instances. Back then there were environement and stuff in the root etc. In the meantime everything moved under the System node which I like. Is there any document/help that describes what needs to be changed in order to get an old instance confirming to this new layout? Norbert

14 years, 8 months

Adding multiple sytlesheets..

by sergio_101

i am using a canned design to start working with, and i was wondering how i could add multiple stylesheets to my design.. i see that when you edit the design, you can choose another stylesheet. it says: 'stylesheets', so i am guessing that i can add more than one.. any ideas? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

14 years, 8 months

Re: [Seaside-dev] Remaining Issues for Seaside 3.0 release

by Reza Razavi

At 12:06 18/04/2010, Lukas Renggli wrote: >This is not supposed to work. Hi Lukas, Well noted; thanks for the clarifications; I'll adapt my design and implementation, as I was expecting it when decided to move from 2.8 to 3.0. Regards, Reza

14 years, 8 months

Re: [Seaside-dev] Remaining Issues for Seaside 3.0 release

by Lukas Renggli

Please, to the Pier list, this has nothing to do with Seaside 3.0 release! > 2. You should not #call: from anywhere within the command execution of > Pier. > > I don't call from within the command execution of Pier either (I'll send a > short email to the Pier mailing list to explain this). Yes, it is. Both #onAnswerCommand: and #onChangeContext: are in the middle of Pier specific command processing. They should not be interrupted, suspended and (multiply) resumed at a later point in time by a #call:. This is not supposed to work. Lukas > To see the exact issue that I talk about, please just change the following: > PRContentsWidget >> onChangeContext: aContext > super onChangeContext: aContext. > self call: WAFlowConvenienceFunctionalTest new > > No change is necessary in #onAnswerCommand:. > > Then, if you point your browser to http://localhost:8080/pier, you should > get that Seaside error. > > My goal has basically been to clarify whether that's an expected behavior in > Seaside 3.0 or a bug? > > FYI, I just double checked with the current distribution of Pier (Pharo0.1, > Latest update: #10374), which looks like still based on Seaside 2.8, and the > above change doesn't raises an error. On the contrary, the WAFlowTest > application (that replaces WAFlowConvenienceFunctionalTest, since absent > from that image) is launched and looks like working OK (although I perfectly > believe you that this may have its own *internal* issues, as you described > above). > > Regards, > Reza > > > > _______________________________________________ > seaside-dev mailing list > seaside-dev(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > -- Lukas Renggli www.lukas-renggli.ch

14 years, 8 months

How the control flow is passed from Pier to Pontoon

by Reza Razavi

Hi, This is a follow up to a current discussion within the *Seaside-dev* mailing list, with the goal of clarifying how the control flow of Seaside, caught by Pier, is passed to Pontoon. Just to situate the context, let me add that Pontoon is the name of a framework under development for implementing by reuse and extension web applications with integrated on-line flow modeling and execution functionality. It heavily draws of community work on Smalltalk, Seaside, and Pier, that I'd like to take the opportunity to thank for the quality of their work, and as a community as a whole. Pontoon uses Pier in several ways. I'll progressively communicate more on that. The one which is of interest here, is the Pier extension to Seaside's Request handling, that specifically comes with a remarkable mechanism for handling Contexts, as, roughly speaking, associations of structures and commands. To keep the design and implementation as consistent as possible with Pier, while ensuring the execution of on-line defined flow models, Pontoon parallels the #execute protocol of PRCommands, and typically catches the control as follows: - WAActionPhaseContinuation >> handleRequest - WAActionPhaseContinuation >> runCallbacks - PRPierFrame >> update - PRContentsWidget >> onChangeContext: - AAsFlowModel >> execute The *trick* consists simply in creating PRContexts that point to Pontoon flow models, instead of Pier Commands. Once a Pontoon flow model takes the control, it determines how it further flows. Given that flow models may be defined on-line, this means that end-users may determine themselves the rules that underlay that flow. In other terms, the flow of control for the behavior that users are concerned about is not necessarily *hard coded*. This is specifically useful when: - The control flow can only be known at runtime (with applications, for example, to support daily life activities), and - The control flow is subject to frequent changes in time and space whilst the web application is already deployed (for examples of application domains, please see <http://adaptiveobjectmodel.com/>http://adaptiveobjectmodel.com/). Pontoon flow models implement their own specific #execute logic, which includes handling concurrent execution, persistency, atomic execution, and exceptions, while remaining consistent with those of Pier, and reusing them whenever possible. As *meta-described composite commands*, flow models may #call: Seaside components. This allows end-users defining on-line their own models of interaction among a set of *primitive* software services, including Seaside components. As soon as the issue we are discussing on *Seaside-dev* is addressed, I'll set-up a demo web site, and post the url here. Regards, Reza

14 years, 8 months

Re: Side effect in RFBServer >>encryptPassword:

by Reza Razavi

At 13:36 17/04/2010, Lukas Renggli wrote: >I guess that's a security measure. Sure, but really tricky and uncommon, although extra easy to fix once you know it. >Yes, but RFB is highly dependent on Pharo, so it doesn't really make >sense to make it also depend on Grease. That's true. Maybe then we could simply add a comment somewhere. Cheers, Reza

14 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki April 2010