Avi Bryant <avi at beta4.com> wrote:
> Sigh, I was hoping I would get to bed before anyone would reply to this.
> I'll respond quickly now, more fully after I've had some sleep.

I am in Europe so its early here... :-)
 
> Goran writes:
> 
> >My next improvements move a bit in this direction but my motivation for
> >those improvements is not so much that I want to separate the webtech
> >from Smalltalk in order to have different programmers working on them. I
> >just don't really think that is feasible.
> 
> Whether or not it's feasible to have different programmers working on them
> from the start, it was a major design goal for me that you should be able
> to tweak your templates with Dreamweaver or some such tool at any point in
> development - so that you can at least have the designers work on the
> HTML once the basic skeleton is there without any conflicts.  We take this
> fairly far - for example, the only addition to HTML the framework requires
> is that every dynamic element must be assigned an id, and the simplest way
> to do that looks like, for example
> 
> <input iowa:id="firstName">
> 
> but the parser also treats any attribute starting with an @ sign as the
> id attribute, so
> 
> <input name="@firstName">
> 
> would also work.  This is to take advantage of the way WYSIWYG editors
> provide dedicated edit boxes for certain attributes of certain elements -
> just stick the ID wherever it's convenient.  (This isn't actually built
> into the parser, btw, but it's one of the standard macro expansions that
> gets run - and yes, you can add your own).

Nice. Hmmm. Separation is of course good in itself as long as it doesn't
make
things too "secret".

> >Another thing - you have bindings, Swiki (at least the old one) had
> >something called UrlMaps, the Java Tomcat world
> >has these things too. I decided to NOT have any bindings (simpler and
> >less places to change) of urls onto methods
> >and instead equalize the url path with the method names on the View
> >instances. Jury will tell.
> 
> The urls are actually all generated by the framework, so the mapping
> isn't as simple as between urls and method names.  However, I think the
> default bindings provides something similar to your direct method mapping.
> For example,
> 
> <a href="@delete:">Delete Item</a>
> 
> will create a link with an ID of "delete:" - this will default to being
> bound to the #delete: method.  However, if for some reason you need to
> change the default, you can specify in the bindings
> 
> (template elementNamed: 'delete:')
>   set: #action toMethod: #remove:
> 
> One major reason you might want to do this is if the method it should be
> bound to changes depending on context.  This is less common for method
> bindings than for most others, however, and I think I almost always just
> specify the name of the method in the html.

Ok, sounds good. In this respect our two frameworks both still suffers
slightly from the fact
that we need to synch the ids in the HTML with the code. Info in two
places.

Currently I have my "ids" mostly in the same method that is "named".
Which means
that even though its info in "two places" (both in the HTML and the
method name itself)
it's easy to keep them in synch.

I wonder how this could be even more improved...

> >> removeItem: anItem
> >> (self confirm: 'Are you sure you want to remove the item ', anItem)
> >> ifTrue: [items remove: anItem. self inform: 'Item removed']
> 
> >Now, this is cool. I think Stephen Pair described a similar feature to
> >me at the last OOPSLA.
> >Hmmm. This can have both positive and negative sides, no?
> 
> >+ Cool. And neat. Hides the Http flow of requests from the developer.
> >- Sneaky. Hides the Http flow of requests from the developer.
> 
> I don't think of it as hiding the http flow - who *cares* about the http
> flow?

Well, I do! :-) What I meant is that I have been burnt earlier by 4GL
tools,
complicated frameworks etc. that tries to hide too much and thus only
"trips me up"
because it does a lot of smart things behind my back. It all depends of
course on how
good it's implemented.

My framework tries to be really "concrete" in that it doesn't try to
hide anything really.
Well, some things I will try to "hide" (HTML stuff) but not the flow I
think.
"HttpView" requires some knowledge on how things "work" in webland.

But I hope that will turn out to be a strength somehow! :-)

> What it does is brings the actual *program* flow to the fore,

True.

> which is much more important.  (In case it wasn't obvious, I've long since
> given up any idea of being lightweight/bare metal anyway.  HTTP is just
> too low level to be interesting).

Well, this is probably where we differ a bit in "design". But both
approaches are interesting
for different tasks. My framework (or similar ones) might be nice if you
are doing
simpler stuff and yours if the system is more complex.
 
> >> - pages or entire applications can be embedded as subcomponents within
> >> another page, or wrapped around them. This allows complex widgets like
> >> trees, tabs, navbars, etc to be built and reused. Subcomponents use the
> >> same transparent bindings system as form elements to sync data with  their
> >> parent page.
> 
> >Ah, yes, a bit like what I was aiming for. Do you have this part working
> >today?
> 
> All of what I described works today.  If you want to know what'll work a
> month from now, that'll be a whole other list... ;-)

Nice! Again - this sounds like a really nice framework. It would be
interesting to
build some simple "demo apps" in both our frameworks and then study
strenghts and weaknesses.

> Ok, time to sleep.
> Avi

Sure! I am going to lunch. :-)

regards, Göran