Cheers,
Miguel Cobá

I am really starting to need something like this. I’ll either (muddle
through) building it, or beg or borrow it. Any chance you could share your
code for this e.g. as a fileOut?

Thanks - Sophie (p.s. sent email, but never know with spam filters …)

Agreed, but unless you are self employed, not always realistic. Microsoft certain is in love with this direction and it is certainly not helping the enterprise level consultant. See InfoPath, SharePoint “development platform”, Oracle, etc.

I’d just say no. You want something like that, go look at DabbleDB, Salesforce, WuFoo, etc, and when you figure out that isn’t really what you want, come back, and we’ll talk about what you want me to build and maintain for you.

End user programming is a myth, they don’t really want to program, they just want to save money and think that’s the answer. Once they try out such a system and run into its limitations, they’ll either accept them, or change their mind and decide they have to pay a programmer to get what they really want, which is usually something simple and highly custom.

Things like DabbleDB, Salesforce, and WuFoo are just way to complex for your average user, they want apps to use, not meta apps that can build apps they can use. The people who want meta apps, are middle men who think they can build and brand apps to sell to end users.

Smalltalk is definitely a breath of fresh air since there are few people imposing that I generate GUIDS and XML files simply to write “hello world” in some terrible bloated piece of garbage software. Working with everything from windows driver programming to Outlook programming w/ MAPI to ASP.NET w/ AJAX has really made me appreciate Smalltalk so much more then when I first touched it in the 80s. I swear there was a time in C /MS world especially where though you maybe had to write a VESA driver and GUI for your app, it was easier doing that than dealing with some wannabe developer end user system/framework/builder like we get now.

Same here, the code is great, but I don’t like the design. The problem with Pier is the same as the problem with many frameworks… someone else wrote them. I’ve come to the conclusion that the only CMS framework I’ll ever be happy with, is my own. Seaside gives me too much power to have to put up with someone else’s code.

So my advice is, build your own, there’s nothing like knowing every line of code inside and out, and you’ll never be stuck trying to figure out how to make it do something it wasn’t intended for.

I gave up on the idea of end user programming, I’m a developer, and it’s just easier for me to hop in and add something that to build some uber meta system that just serves to replace me. Smalltalk is my runtime configurable uber system, and I can make changes just as fast in it as some homebrew webified IDE that I’d cook up to give to users.

You have a good point regarding the practicality of user generated forms. For my particular application, user generated forms are a part of a whole, mainly because that is what the client wants. In other words, most of the time I am not creating components that use user generated forms, rather the forms are more of an add-on for when the pre-canned stuff is not enough. It seems whether I use pre-canned or user generated forms, I need to add metadata to all my models because the canned objects may have to evolve to support a user generated form, for instance when type Customer is extended to VIPCustomer, necessitating 3 more fields.

I suppose I like the fact that Magritte seems to allow me some flexibility designing the components. I can either just create a single component that uses the meta-data as needed for things like the memento cache, or create a series of components for the auto-generated forms. Obviously, the auto-generated forms are not going to be as powerful, but I think they are better than nothing at all.

Case in point, image a CMS system. With each page, there is a potentially unknown amount of meta-data that needs to be added. In some cases, maybe it is just keyword and tags will suffice, but in others it may be adding business fields. I know that Pier does some of this and uses Magritte, but I don’t really like the user experience in Pier despite the quality of the code, and it’s not really that applicable for everything in my case anyway. How would you add meta-data to something like this without a dynamic such as Magritte? Would this always be time to have a developer intervene?

Certainly the surge in popularity of the numerous CMS and Portal products (SharePoint again for example) prove that there is at least some desire for user defined models. I think it’s a bit different in the case of dabble db since it’s pretty much ground 0 until you do some work, vs a system where you have a lot of pre-canned stuff and then realize the need to expand it. Where these systems suck is the nightmare of XML, assembly/jar hell, and horrible relational mapping (rows acting as columns ala SharePoint’s database). The Magritte way is probably a lot better compromise than the existing implementations I have seen.

I certainly agree and appreciate your practicality. Coming from the Assembly/C , Java, and .NET world myself mainly, I see my share of ridiculous over engineering and complexity. If you’ve ever worked with Microsoft CRM, Peoplesoft, SharePoint, or Oracle product, you are definitely aware of just how badly these guys glue stuff together when it needs to be dynamic. I suppose the only way I’m going to find out for myself with this is to move beyond my proof of concepts I have built with Squeak and into something more tangible.

My problem with it isn’t conceptual, it’s practical. Every time I have to move beyond a demo and build a real complex form with field to field interactions and Ajax stuff, I have to start building custom seaside components and figure out how to tie them together somehow when fields interact. Suddenly, it’s much easier to just build a single Seaside component for the whole form, rather than a component per field.

Put simply, Magritte is too abstract, Seaside is the perfect level of abstraction (for me) to allow the control necessary. Rather than composing forms from subcomponents, it’s easier to have a single form component that uses metadata to render itself dynamically. This approach works better for very customized programatically generated Ajaxy forms because I can drop into raw Seaside whenever necessary to customize it. I don’t want or need runtime generated forms, frankly, users can’t handle that no matter how slick you try and make it. There will always be those who build things, those who use them. People don’t want to build their own forms… unless they’re developers. Dabbledb has found out just how many of their users are actually semi-developers trying to use dabble to sell custom applications.

If you want user built forms, Magritte is probably much more your cup of tea, that’s what it was designed for. Just be aware, if you want Ajax, you’ll likely have to build all of your own Magritte components anyway, the default ones are very vanilla. But, runtime building and modification of descriptions is what Magritte was meant for.

I have had my eye on Magritte for many months now and I have been reading your blog, mailing list posts, and Lukas’s posts from the mailing list. As with a good deal of frameworks/idioms/etc. written by others, I spend a lot of time trying to listen to the “bad” chatter which is often more telling than the good (I have reviewed the source and agree that it is great OO code).

Consequently, your last comment about how you’ve strayed from Magritte has really made me question whether I should use it at all. I suppose it depends on the particular project and what goals. I fear like you mentioned in another comment that I will just end up building more or less the same thing.

As part of a much larger system, I want to create a system that does some of the following:

1) Allows the user to dynamically add fields to a form. A good example of this in production is Microsoft SharePoint, albeit one that does it rather poorly IMO.

2) Allows a user to add simple, but possibly chained dynamic validation rules. This is something SharePoint sucks at beyond “required” fields, which would be a simple #isRequired type idiom if I wanted to go that route.

3) Ability to define new simple business objects based off existing primitives, for instance create a “Actress” based on a “Person” object, then add a “Movies” (collection of movies) to the object.

4) AJAX, AJAX, AJAX. No, not for gimmicky purposes, but because parts of this application are very “desktop” like and constant reloading really is more of a pain in some places.

5) Lots of self-contained widgets that broadcast events if they need to talk to/provide data to other widgets

I plan not to really use the built-in Magritte forms templates and instead implement my own custom, theme-able forms. I think though what I am really interested in is not so much generating these forms well automagicallly, but the possibility of manipulating the meta-data at runtime. For instance, creating a description at runtime. I would prefer to avoid the meta-data route in some ways for reasons you mentioned because I really would prefer to just have the application somehow generate a concrete smalltalk class, but I am not so sure that is possible/good idea when you’re dealing with hundreds of images scaled out. Ideas?

I really like the way Lukas implemented security and other functionality in Pier using Magritte. This is what originally attracted me, not really the forms part, but it seems like it could be a daunting task really learning how to effectively use what he built despite documentation. Building my own system would take a lot of time, but in a sense it would do exactly what I want without mucking things up by being too generic.

Do you think Magritte is still a good thing to use in a system like this? Thoughts? Thanks.

Any chance you can share this? Even if very specific to your style I’m sure it would be very useful to Seasiders in general.

Thanks.

However, in truth, I’ve become less and less enamored with Magritte as I find myself having to jump through too many hoops and remember too many details about its object model to really customize it.

Sebastian’s comment above really got me to thinking about just how useful Magritte is. Ajaxify’ing Magritte is no easy task especially when you want to have several fields tied together in various ways.

I’ve come to realize the problem is Magritte is so meta that it forces you to solve the meta problem you’re having rather than the actual problem you’re having. You can’t easily rig up something to solve a problem with a particular form without having to solve it for all forms.

For example, making a select box be redrawn via Ajax when another one changes. I did this, and I had to wire up descriptions to be dependents of other descriptions, and then extend the container to send messages between the individual views, it was a pain, I could have (and have) done this much faster by just dropping into raw Seaside.

So, long story short, I’ve decided I prefer the approach taken by WAFormDialog, a single superclass that can be extended to create specific forms quickly. I don’t actually use WAFormDialog because I also like using metadata, so I’m hacking up my own form generator that uses pragmas from the model to control how it renders forms based on a few simple conventions that suite my style. It allows me to easily override the automation on a per field basis to drop into Seaside and manually render anything that needs to be Ajaxified or fancier than the defaults provide. So far I’m liking this approach much better than Magritte.

So, I’d recommend taking a look at WAFormDialog and then hacking up something similar that suits you. Seaside’s reusable components are great, but I’m finding that mostly, I don’t want to reuse components I didn’t build myself because they are never quite what I want and it’s so easy in Seaside to simply build your own component that is *exactly* what you want, no more, no less.

I doubt I’ll be using Magritte much anymore, but I learned a lot from it. It’s a great framework, but it’s just not what I need.

My browser customization can be found in the class SentorsaBrowser. Sebastian, I appreciate the thoughtful comments, sometimes one spends so much time learning something that you forget just how complicated it seems, I’m glad I revisited my usage of Magritte and I much prefer my own method to using it.

Could you expand a bit on the other features Magritte offers, and why you don’t plan to use them? e.g. are the default Viewers not as useful as the default Editors? Do you just need too many customizations to every viewer to benefit from Magritte, and not so for forms? Are the editors easy to Ajax-ify?

Also, is there a set of components you would recommend to get started with, both for Seaside and Magritte?

Lastly, where (in your image) would I find the code that creates your IDE customizations e.g. for description generation?

Thanks!

While you can customize every part of Magritte for each project, you generally don’t. What you end up doing is customizing once, so it works the way you like, and you reuse those customizations in every project you do.

The descriptions themselves can be auto generated by your IDE when you create accessors, and quickly customized with properties like #beRequired, #default:, #options:, #addCondition:labelled:,#min:, #max, etc. Believe it or not, it does result in having to write much less code and a project wide consistency in how forms look and feel that you won’t get by manually building your forms. It’s also much faster than manually writing your forms.

A better way to think of it is this, if you manually build your forms, and then factor your technique into something more reusable to save yourself time in the future, at some point, you’ll end up with something similar to Magritte. At that point, you’ll understand you should’ve just used something like Magritte to begin with.

It’s nothing more than a meta-model that allows you to add extra meta-data to your objects so that generic view components have everything they need to be bound to the model in a reusable fashion.

I thinks this examples could be put in some magritte class comments…

Thanks Ramon, I was missing your posts ;)

Maybe a post on how to link seaside/magritte and database would be cool :) Is it in relation to a special accesor, for instance MABlockAccessor ?

Thanks

Since the descriptions are part of the domain class, I could just consider them the constraint system and give my domain objects the ability to validate themselves against their descriptions anytime. I think that’d solve my objections and meet the requirements you laid out above. I appreciate your thoughts on the matter.

Person constraintOn: #dateOfBirth is: [....]

Consider multiple channels that manipulate that domain model. On some channels the consistency checks may be enforced in the UI layer itself, on some other channels the checking should be done in a “server-side” call. This decision can be late bound (in an extreme case, perhaps even entirely dynamic on each call, if the call carries enough contextual info for validations). Just as Magritte creates components by walking descriptions, it could follow a logic that knew something about the properties of a channel (whether shallow or deep, determined dynamically on each call or relatively static) to customize which, how, and where constraints are checked.

If some constraints vary depending on component used (e.g. free-form text field for a date vs. a date picker) the composition would be a bit more involved but same basic idea.

I think the constraints should be defined, just once, alongside the domain model. Whether these are converted to conditions that are checked the way Magritte does should be a later bound decision, possibly dynamic.