seaside-dev September 2017

seaside-dev@lists.squeakfoundation.org

4 participants
4 discussions

"Bootstrap" project for Seaside with separated Magritte support in a new project "BootstrapMagritte" on STHub
by Torsten Bergmann 16 Jul '18

16 Jul '18

Hi, The bundling with magritte polluted the repo and the Bootstrap project with stuff that was not really needed for "Seaside + Bootstrap" only. Also a "Bootstrap-Demo" package appeared that was more a demo for magritte than for Bootstrap. Since there already was an "Bootstrap-Examples" package this added more confusion (at least on my side). I now took action and cleaned up the Bootstrap project again to remove the magritte stuff. If one wants to to use Bootstrap with Seaside he does not necessarily have to go the Magritte path, so IMHO this was necessary. The magritte stuff for Bootstrap is now hosted as an own separate project on STHub which would also help to see to which part code additions really belong. As a result: ============ 1. The Bootstrap project now again only contains and loads the initial three packages: - Bootstrap-Core - Bootstrap-Tests-Core - Bootstrap-Examples assembled by the known ConfigurationOfBootstrap 2. The Magritte support on top of Bootstrap is now separated in an own project to avoid too much mixin. See "BootstrapMagritte" on SmalltalkHub. The new repo "http://smalltalkhub.com/#!/~TorstenBergmann/BootstrapMagritte" has the same commiters as the old one, so feel free to continue with your work. This project includes two packages: - Bootstrap-Magritte-Core (former Bootstrap-Magritte) - Bootstrap-Magritte-Examples (former Bootstrap-Demo) assembled by a new ConfigurationOfBootstrapMagritte for this particular project 3. The Bootstrap/ConfigurationOfBootstrap is now available as - a release version 0.4.0 for Seaside 3.0.9 - a release version 0.5.0 for Seaside 3.0.10 - a release version 0.6.0 for Seaside 3.1.0 (#stable) - a development version 0.7.0 for Seaside 3.1.0 for new stuff 4. The CI for Bootstrap is green for Pharo 2.0 and now also Pharo 3.0 5. The config browser is updated for Pharo 2.0 and Pharo 3.0 with the "Bootstrap" package So you can now also open a fresh Pharo 3.0 image, open World menu -> Configuration Browser to load "Bootstrap". Then run ZnZincServerAdaptor startOn: 8080 and start coding your web application with the latest Seaside 3.1.0. Next steps: Setting up a CI for the new project "BootstrapMagritte"/ConfigurationOfBootstrapMagritte Have fun! Bye Torsten

3 7

DOM element ID registry at the component
by Esteban A. Maringolo 22 Sep '17

22 Sep '17

Hi all, me again :) Related with the previous mail about naming script builder selectors, another thing I find myself repeating over and over, is the creation, initialization and of course access of instance variables holding references to dynamically generated element id (vía `html nextId`). Given that today's webpages, even the simples ones, use a lot of Javascript with Jquery at the client side, wouldn't it be a good addition to have a registry of these IDs at the component level? This way we would avoid creating lots of instance variables just to keep a reference to those IDs. In some cases that reference is only needed in the context of a single method, so a temporal variable is enough, but if the code is complex and well factored you can only pass these IDs as arguments or make the temp an instance variable. So I'm thinking about having something like: renderSomethingOn: html self atId: #content put: html nextId. html nextIdFor: self at: #heading. html div id: (self atId: #content); with: [html heading id: (self atId: #heading); with: 'Foo baz'. "..." ]. WAHtmlCanvas>>#nextIdFor: aWAComponent at: aSymbol aWAComponent atId:aSymbol put: self nextId These selectors aren't well thought, but the idea is that you can assign whatever you want to the registry, or you can use the canvas nextId to assing it automatically to the registry. The registry could be lazy initialized, so components that never access it won't have an extra, empty instance of it (a GRSmallDictionary probably). Pros: - It would save the use of lots of instance variables - It would "standardize" a way to access those ids other than #nextId/#lastId without requiring accessor methods for the variables. Cons - It would require an extra instance variable at WAComponent to reference the registry To compensate the last one there could be a particular WAComponent subclass that has this feature, but I suspect most instances would subclass from it, so it would be the same as doing it in WAComponent directly. What do you think? Regards, Esteban A. Maringolo

3 5

What happened to GRExceptionBasedDynamicVariable?
by Philippe Marschall 05 Sep '17

05 Sep '17

Hello Back when we discussed the WADynamicVariable refactoring I mentioned introducing a GRExceptionBasedDynamicVariable for easier porting. I can't it, what happened to it. Cheers Philippe

2 2

State of the Seaside repositories
by Philippe Marschall 04 Sep '17

04 Sep '17

Hello I wanted to work on Seaside during ESUG unfortunately I don't know what the state of the Seaside repositories is. To sum up - What is main development the repository for Grease 1.3? - What is main development the repository for Seaside 3.2? - What is main development the repository for Seaside 3.3? Basically I need to know whether I should commit to SmalltalkHub or GitHub. And if GitHub to which branch. In addition I noted that the GitHub and SmalltalkHub repositories are out of sync. There where several commits and packages that made it to SmalltalkHub Seaside32 but never ended on GitHub. If GitHub is the main repository I need to know whether we use filetree or IceBerg. In addition I need to know how to set them up and use them. See my mail from June [1]. Right know I can't contribute to Seaside which is quite frustrating. [1] http://lists.squeakfoundation.org/pipermail/seaside-dev/2017-June/007098.ht… Cheers Philippe

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev September 2017