smallwiki

smallwiki@list.inf.unibe.ch

2312 discussions

by Diego Lont

Hi all, Recently there was a question about Magritte extensions on the Pharo users list. It has been a while that I was really involved in developing on (QC)Magritte and doing stuff on the web, but on my todo list, there is feeding back the improvements on Magritte I have made for QCMagritte to Magritte itself. And while doing so, adding tests and cleaning up code where needed. The first extension I would like to feed back into Magritte is the Builder. The background of the builder is the following: - Having a custom component set, and wanting to use this custom component set can be very tiresome for larger applications, because you have to set a component class for all descriptions. - Also it breaks the layering Magritte is trying to build in, as you need to "pollute" your model descriptions, with all kind of stuff, that determine how everything looks like. With stuff that belongs in your UI code instead of your model code. I believe that the builder is a solution for this problem. The actual builder can be injected as an extension (for an example see the QCMagritte demo) and processes all descriptions. As it is a visitor, it can replace or enrich your descriptions with whatever you need in your UI based on the type of description. The builder affects the way the Magritte description is created, so the package contains an override of magritteDescription. If I would implement this on Object (the most logical point), I would need to put the builder into Magritte-Model. Having no builders, this would of course not affect the returned description. Does anyone object to putting this here? And if you have objections, do you have a suggestion to do this elsewhere? Cheers, Diego

7 years, 1 month

MAReport body scrolling with thead data 'fixed'

by dtrussardi＠tiscali.it

Ciao, i have a Magritte Report based on same descriptions. Now i need to rendering the relative instance inside a div for scrolling the data. All works fine but the scrolling works on the thead data rendering at the top. In this case i lose ( not display ) the thead data when i scrolling down the data. My goal is to 'fixed' the thead data at the top and when i scrolling only the body data scrolling. The same considerations is relative to the tfood of the MAReport. I attempted to fixed the thead with: .divForScrolling table thead { position: absolute; width: 99%; border: 2px solid; } It 'fixed' the thead data at the top of the divForScrolling but it lose the resizing of the thead td width. This in the both case when defined the table-layout of the MAReport table fixed or auto . divForScrolling table { table-layout: fixed; width: 100%; } In substance with the thead position: absolute the body td width size change when resizing the MAReport ( change the size of the web page for fixed table-layout or change the data for auto table-layout ) but the relative thead td width not. Has anyone else had such a requirement / plan to solve it out there? Thanks, Dario P.S. Has anyone solved these problems by using other tools ( library ) ?

7 years, 1 month

MAReport body scrolling with thead data 'fixed'

by dtrussardi＠tiscali.it

7 years, 1 month

Is there an Undo/Versioning solution based on Magritte?

by Esteban A. Maringolo

Hi all, I'm trying to implement a way to have versions of the contents entered through a form so I can revert the object models to an early state, very much like the page history edits in Wikipedia, but with more fields than just the text content. This solution should provide a feature to store the contents not only of the descriptions in the container, but also descriptions contained in referenced descriptions (via MAReferenceDescription). I'm about to write my own, but if there is something out there, I would like to see if it fits our needs, or could be easily modified. Regards! Esteban A. Maringolo

7 years, 1 month

Magritte3 on Pharo7

by stephan

I've started making some changes to run Magritte on Pharo7. In Pharo7, a number of traits were flattened and are no longer used. That results in #label not being available Stephna

7 years, 1 month

Port of builders to Magritte-Model

by Diego Lont

Hi all, As announced previously I ported the builder back to Magritte, as I believe it was a missing piece in Magritte. A mail does not suffice to give the details, and in the past I did 2 presentations on this topic (dry-ing Magritte, https://www.slideshare.net/esug/drying-magritte?next_slideshow=1). I also extended the tutorial (build in with QC-Magritte, load QC-Magritte, and start a web-browser on http://localhost:8080/) with a chapter “technical details” where I made another effort in explaining why we need builders. If this gives questions, please ask them. Also I am not 100% sure a builder is the correct term: so if there are people with better suggestions, please post them. The coming weeks I will fill in the last blanks: - add testcases specific to the builder. The old ones still run, ensuring no builders == no change. - more work on tutorial. Of course it motivates me, when people comment or ask questions, so I know it is used. So thanks Udo for asking a question concerning QCMagritte, this helped me at least finish this far. Regards, Diego

7 years, 7 months

QCMagritte: (Bug?) Groups always collapsed

by Udo Schneider

All, I think I hit a bug in QCMagritte. If you have groups (or objects embedded via MAToOneRelation) theses are rendered as collapsed groups by default. However it is not possible to uncollapse them. This is IMHO due to a bug in MAContainer>>#isCollapsed:. As far as I read the code in #isCollapsed:/#setCollapsed:for: and #defaultCollapsed groups, it's not possible to un-collapse groups because neither #setCollapsed:for: nor #isCollapsed: *sets* the property. Both use #at:ifAbsent:. Changing #isCollapsed: to use #at:ifAbsentPut: seems to solve the issue: isGroupCollapsed: aGroup ^ (self propertyAt: #collapsedGroups ifAbsentPut: [ self defaultCollapsedGroups ]) includes: aGroup CU, Udo +

7 years, 7 months

Re: QCMagritte: QCObject vs. QCParentObject

by Esteban A. Maringolo

This is why I call it "ModelPart", because the parent/child relation is alike but not always so. It's "part" of a whole (its owner), but not necessarily a child. Also the relation is of aggregation, the lifetime of the part is, as much, as long as the lifetime of its owner. I.e. an InvoiceIem is part of an Invoice but won't exist if the invoice is deleted. Regards, El abr. 30, 2017 12:10 PM, "Stephan Eggermont" <stephan(a)stack.nl> escribió: On 29/04/17 14:40, Diego Lont wrote: > Good point. When no one objects I will rename QCParentObject into > QCChildObject. > Hmm. Aren't they all children? Isn't the more important aspect ownership? Let's iterate over the name some more. Stephan _______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki

7 years, 7 months

QCMagritte: QCObject vs. QCParentObject

by Udo Schneider

All, I can't really understand the difference between QCObject and QCParentObject and when to use which. From reading the source I can guess that a QCParentObject allows you to access the ApplicationModel using #model (through it's parent ivar). But is this all? CU, Udo

7 years, 7 months

Latest Magritte version per Smalltalk dialect

by Esteban A. Maringolo

Hi all, Do we know what is the latest Magritte version available in each Smalltalk dialect? I know Pharo/Squeak share code, but I'd like to know if there is recent version of it in Cincom Smalltalk (VisualWorks 8.2), or if there is somebody with plans of migrating/using it. Best regards, -- Esteban.

7 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki