Janko Mivšek | 10 Feb 16:37 2012
Picon

Re: Vision for Aida

Hi Bob,

You just inspired me to write down my vision and future plans for Aida,
so let me start with that:

Main *Aida vision* from the start is to extend the Smalltalk philosophy,
elegance, simplicity, power to the web applications as well while
preserving all those beauties of Smalltalk.

And to be on the *bleeding edge of web technology* with Smalltalk all
the time. Which we are. I'm most proud that initial architecture was set
good enough to be adaptable through all that time since 1996 and that we
are not stuck even now supporting the current HTML5 wave.

And here are the plans. Short-term, long-term? Well, we'll see :)

1. *Documentation*! It seems Aida core features are stable enough now
   that we can document it and that this documentation will last for a
   while without needing to update it constantly;

2. More *HTML5*! like FileSystem, DragDrop, Video and Audio etc etc;

3. More *realtime*, actually realtime anything, everywhere. WebSocket
   standard is now de-facto complete and in a year all browsers will
   support it. What I mean by realtime anything, everywhere? Any data
   you show everywhere on your web page will be updated in realtime,
   that is, immediately when data changes. And this will be switched on
   by default!

4 More *client*! That is, more processing moved to web client with
(Continue reading)

Robert Calco | 10 Feb 16:59 2012
Picon

Re: Vision for Aida

Hi Janko,

2012/2/10 Janko Mivšek <janko.mivsek <at> eranova.si>
Hi Bob,

You just inspired me to write down my vision and future plans for Aida,

:)
 
so let me start with that:

Main *Aida vision* from the start is to extend the Smalltalk philosophy,
elegance, simplicity, power to the web applications as well while
preserving all those beauties of Smalltalk.

I would really like to see Aida make coding in HTML/CSS/JavaScript a relic of the ancient past (I guess that would be Web 2.0 by now; what are we up to...4.0?).... 

I like the direction WebSharper (F#) and LiftWeb (Scala) have been going. I really am intrigued by Amber, Cappuccino, and CoffeeScript. Aida web should 'Aid' in those kinds of experiments, only with Smalltalk and some kind of clean MVP pattern applied with rigour on the server and the client side.

I like the idea behind how Seaside maintains complex state. I am not terribly thrilled with replacing, rather than embracing, the realities of HTTP... it seems to me the overhead of that strategy will only be worth it till a cleaner way to do it RESTfully emerges.
 

And to be on the *bleeding edge of web technology* with Smalltalk all
the time. Which we are. I'm most proud that initial architecture was set
good enough to be adaptable through all that time since 1996 and that we
are not stuck even now supporting the current HTML5 wave.

That is an important plus. However, I'd like to see fewer bugs than have popped up, which give it the appearance of instability. For example, even now, if you want to put the Pharo-Aida-OneClick in a bad state, just log in as admin to the demo site, click Settings -> Sites, and try to go back, or navigate anywhere else. You'll need to invoke the following magical incantations:

SwazooServer stop.
AIDASite default releaseApplicationState.
SwazooServer start.

To you that's not a big deal, you know you've got a bug there. To a new person, that makes you wonder if the framework is stable. That kind of thing.
 

And here are the plans. Short-term, long-term? Well, we'll see :)

1. *Documentation*! It seems Aida core features are stable enough now
  that we can document it and that this documentation will last for a
  while without needing to update it constantly;

Yay! :)
 

2. More *HTML5*! like FileSystem, DragDrop, Video and Audio etc etc;

Excellent.
 

3. More *realtime*, actually realtime anything, everywhere. WebSocket
  standard is now de-facto complete and in a year all browsers will
  support it. What I mean by realtime anything, everywhere? Any data
  you show everywhere on your web page will be updated in realtime,
  that is, immediately when data changes. And this will be switched on
  by default!

Good! 

4 More *client*! That is, more processing moved to web client with
 Amber Smalltalk. Here the end goal is to partition your app in
 runtime where to run. All on server as now, all on client (and
 offline), or parts on server, parts on client. Client parts are
 "emitted" to Amber Smalltalk and sent to a client for execution;

Interesting.
 

5. More *local updating* at the client. On server only data is
  updated while all dependent views are refreshed locally on client;

6. *Automatic forms building* out of domain model, with help of
  forthcoming AidaFields by Nicolas Petton;

Oh, how I long for an Aida answer to Magritte! I really love the concept.
 

7. More *relational domain model* support;

Well, how about: just some decent support for the main persistence alternatives... in-image, GLORP, GemStone, etc.. Some kind of guidance here for noobs would be most helpful. Ahem. :)
 

8. More *JavaScript libraries* supported as Aida Addons;

I think the abstractions for JavaScript and CSS are not yet refined. There is some vision gap there in both Seaside and Aida.
 

9. Aida as provider of *REST-full web services* accessible from other
  web or mobile apps

I have serious secure API needs for my applications. I feel rather insecure right now with Smalltalk vis a vis HTTPS.


10.*Cloud* support, Aida apps as both as client as service provider in
  the cloud;

I like. :)
 

11.*Aida hosting*, both free and commercial.

Would be very nice if there was more of that, yes. :)

I think a twelfth point should be *Tooling*... it needs to be much more intuitive to build sites and apps on the sites in one or more images. A secure Web Development UI would be cool. Wizards in the development image for visualizing what's where would be really helpful.

- Bob
 


Best regards
Janko



S, Robert Calco piše:
> Janko,
>
> I was wondering if you could reveal any grand plans you might have for
> the future of Aida?
>
> What I like about Aida compared to Seaside is its relative simplicity
> and portability. Seaside uses features of Smalltalk that are not really
> portable between smalltalks to do its magic (continuations and pragmas
> being the big ones that I've noticed, which prevent it from being used
> fully in Dolphin, for example).
>
> It feels to me like Aida doesn't try to reinvent too many wheels,
> meaning it's a bit more accessible to people coming from, say, Rails,
> like myself. It has relatively more steak than sizzle, whereas Seaside
> has relatively more sizzle than steak. I like my steak rare ("still
> twitching" is what I tell waitresses at restaurants), so I don't care
> about sizzle so much. That said, my favourite way to prepare steak is
> 'black and blue' -- but it takes a rather industrial-size furnace to
> cook it that way, but, working for a charity, I usually only have a
> couple matches and a little kindling to start my fire pit. ;)
>
> What I don't like about Aida is the documentation, which is a bit
> scattered by topic and somewhat stream of consciousness. Seaside has
> Aida beat hands-down in this department. There are books, well-designed
> tutorials, lots of samples, etc. It's actually very hard, if you're me,
> to ignore that big plus for Seaside.
>
> I think Aida needs a much better, much more in-depth tutorial, that
> really highlights its best parts, and suggests where it's going to get
> better over time. I am not sure I like all the parts of Aida included --
> for example, I've been reviewing the (very involved) Parties/Roles
> packages and it encroaches a lot on my domain model, meaning I either
> have to use all of it or none of it. But maybe I have misinterpreted its
> design? Maybe it's better than my slogging in the code has revealed, and
> I should use it? Some documentation about the rationale for the
> abstractions chosen and how they're implemented would be nice.
>
> What I'd like to see in Aida is a greater commitment to REST and maybe
> XMLRPC API support (seems you're working on that one quite
> aggressively), more of an MVP vs MVC pattern for rendering, and perhaps
> support for rich web clients a la Amber (I see there is WebDAV support
> in Aida, so perhaps you're already intending to go that route), and
> better security (I really need to support HTTPS, and support API keys
> securely). Seaside has done a good job in its HTML API, but Aida's
> abstractions feel somewhat heavy (gazillions of methods). Some
> refactoring of that seems like it could be good.
>
> Neither framework handles layouts, look-feel, or any of the design
> intensive side of web development as nicely as I imagine it could be
> done. This could be an area for huge win in Aida, as I see you've tried
> to make it easy to reskin a site by supplying a new web style. However,
> I tried doing this with the demo app and only just mucked stuff up.
> Again, good documentation about this important area of implementation
> and some idea of what the end-goal is for it would be awesome.
>
> I'm willing to contribute but I need to get up and running and confident
> in what I'm doing still. It's been a bit of a ramp up. But I think I'll
> do well with this choice for what I need to do. I would just like to
> know what the future holds as I think there is still a lot of room for
> innovation in web development, and it doesn't all have to be heretical
> to be on the bleeding edge, so to speak. I'll feel better about Aida
> knowing that it's roadmap is a good one.
>
> - Bob
>
>
>
>
> _______________________________________________
> Aida mailing list
> Aida <at> aidaweb.si
> http://lists.aidaweb.si/mailman/listinfo/aida

--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida

<div>
<p>Hi Janko,<br><br></p>
<div class="gmail_quote">2012/2/10 Janko Miv&scaron;ek <span dir="ltr">&lt;<a href="mailto:janko.mivsek <at> eranova.si">janko.mivsek <at> eranova.si</a>&gt;</span><br><blockquote class="gmail_quote">
Hi Bob,<br><br>
You just inspired me to write down my vision and future plans for Aida,<br>
</blockquote>
<div><br></div>
<div>:)</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">

so let me start with that:<br><br>
Main *Aida vision* from the start is to extend the Smalltalk philosophy,<br>
elegance, simplicity, power to the web applications as well while<br>
preserving all those beauties of Smalltalk.<br>
</blockquote>
<div><br></div>
<div>I would really like to see Aida make coding in HTML/CSS/JavaScript a relic of the ancient past (I guess that would be Web 2.0 by now; what are we up to...4.0?)....&nbsp;</div>
<div><br></div>
<div>I like the direction WebSharper (F#) and LiftWeb (Scala) have been going. I really am intrigued by Amber, Cappuccino, and CoffeeScript. Aida web should 'Aid' in those kinds of experiments, only with Smalltalk and some kind of clean MVP pattern applied with rigour on the server and the client side.</div>
<div><br></div>
<div>I like the idea behind how Seaside maintains complex state. I am not terribly thrilled with replacing, rather than embracing, the realities of HTTP... it seems to me the overhead of that strategy will only be worth it till a cleaner way to do it RESTfully emerges.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
And to be on the *bleeding edge of web technology* with Smalltalk all<br>
the time. Which we are. I'm most proud that initial architecture was set<br>
good enough to be adaptable through all that time since 1996 and that we<br>
are not stuck even now supporting the current HTML5 wave.<br>
</blockquote>
<div><br></div>
<div>That is an important plus. However, I'd like to see fewer bugs than have popped up, which give it the appearance of instability. For example, even now, if you want to put the Pharo-Aida-OneClick in a bad state, just log in as admin to the demo site, click Settings -&gt; Sites, and try to go back, or navigate anywhere else. You'll need to invoke the following magical incantations:</div>
<div><br></div>
<div>SwazooServer stop.</div>
<div>AIDASite default releaseApplicationState.</div>
<div>SwazooServer start.</div>
<div><br></div>
<div>To you that's not a big deal, you know you've got a bug there. To a new person, that makes you wonder if the framework is stable. That kind of thing.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
And here are the plans. Short-term, long-term? Well, we'll see :)<br><br>
1. *Documentation*! It seems Aida core features are stable enough now<br>
 &nbsp; that we can document it and that this documentation will last for a<br>
 &nbsp; while without needing to update it constantly;<br>
</blockquote>
<div><br></div>
<div>Yay! :)</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
2. More *HTML5*! like FileSystem, DragDrop, Video and Audio etc etc;<br>
</blockquote>
<div><br></div>
<div>Excellent.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
3. More *realtime*, actually realtime anything, everywhere. WebSocket<br>
 &nbsp; standard is now de-facto complete and in a year all browsers will<br>
 &nbsp; support it. What I mean by realtime anything, everywhere? Any data<br>
 &nbsp; you show everywhere on your web page will be updated in realtime,<br>
 &nbsp; that is, immediately when data changes. And this will be switched on<br>
 &nbsp; by default!<br>
</blockquote>
<div><br></div>
<div>Good!&nbsp;</div>
<blockquote class="gmail_quote">
<br>
4 More *client*! That is, more processing moved to web client with<br>
 &nbsp;Amber Smalltalk. Here the end goal is to partition your app in<br>
 &nbsp;runtime where to run. All on server as now, all on client (and<br>
 &nbsp;offline), or parts on server, parts on client. Client parts are<br>
 &nbsp;"emitted" to Amber Smalltalk and sent to a client for execution;<br>
</blockquote>
<div><br></div>
<div>Interesting.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
5. More *local updating* at the client. On server only data is<br>
 &nbsp; updated while all dependent views are refreshed locally on client;<br><br>
6. *Automatic forms building* out of domain model, with help of<br>
 &nbsp; forthcoming AidaFields by Nicolas Petton;<br>
</blockquote>
<div><br></div>
<div>Oh, how I long for an Aida answer to Magritte! I really love the concept.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
7. More *relational domain model* support;<br>
</blockquote>
<div><br></div>
<div>Well, how about: just some decent support for the main persistence alternatives... in-image, GLORP, GemStone, etc.. Some kind of guidance here for noobs would be most helpful. Ahem. :)</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
8. More *JavaScript libraries* supported as Aida Addons;<br>
</blockquote>
<div><br></div>
<div>I think the abstractions for JavaScript and CSS are not yet refined. There is some vision gap there in both Seaside and Aida.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
9. Aida as provider of *REST-full web services* accessible from other<br>
 &nbsp; web or mobile apps<br>
</blockquote>
<div><br></div>
<div>I have serious secure API needs for my applications.&nbsp;I feel rather insecure right now with Smalltalk vis a vis HTTPS.</div>
<div><br></div>
<blockquote class="gmail_quote">

<br>
10.*Cloud* support, Aida apps as both as client as service provider in<br>
 &nbsp; the cloud;<br>
</blockquote>
<div><br></div>
<div>I like. :)</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
11.*Aida hosting*, both free and commercial.<br>
</blockquote>
<div><br></div>
<div>Would be very nice if there was more of that, yes. :)</div>
<div><br></div>
<div>I think a twelfth point should be *Tooling*... it needs to be much more intuitive to build sites and apps on the sites in one or more images. A secure Web Development UI would be cool. Wizards in the development image for visualizing what's where would be really helpful.</div>
<div><br></div>
<div>- Bob</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br><br>
Best regards<br>
Janko<br><br><br><br>
S, Robert Calco pi&scaron;e:<br><div><div class="h5">&gt; Janko,<br>
&gt;<br>
&gt; I was wondering if you could reveal any grand plans you might have for<br>
&gt; the future of Aida?<br>
&gt;<br>
&gt; What I like about Aida compared to Seaside is its relative simplicity<br>
&gt; and portability. Seaside uses features of Smalltalk that are not really<br>
&gt; portable between smalltalks to do its magic (continuations and pragmas<br>
&gt; being the big ones that I've noticed, which prevent it from being used<br>
&gt; fully in Dolphin, for example).<br>
&gt;<br>
&gt; It feels to me like Aida doesn't try to reinvent too many wheels,<br>
&gt; meaning it's a bit more accessible to people coming from, say, Rails,<br>
&gt; like myself. It has relatively more steak than sizzle, whereas Seaside<br>
&gt; has relatively more sizzle than steak. I like my steak rare ("still<br>
&gt; twitching" is what I tell waitresses at restaurants), so I don't care<br>
&gt; about sizzle so much. That said, my favourite way to prepare steak is<br>
&gt; 'black and blue' -- but it takes a rather industrial-size furnace to<br>
&gt; cook it that way, but, working for a charity, I usually only have a<br>
&gt; couple matches and a little kindling to start my fire pit. ;)<br>
&gt;<br>
&gt; What I don't like about Aida is the documentation, which is a bit<br>
&gt; scattered by topic and somewhat stream of consciousness. Seaside has<br>
&gt; Aida beat hands-down in this department. There are books, well-designed<br>
&gt; tutorials, lots of samples, etc. It's actually very hard, if you're me,<br>
&gt; to ignore that big plus for Seaside.<br>
&gt;<br>
&gt; I think Aida needs a much better, much more in-depth tutorial, that<br>
&gt; really highlights its best parts, and suggests where it's going to get<br>
&gt; better over time. I am not sure I like all the parts of Aida included --<br>
&gt; for example, I've been reviewing the (very involved) Parties/Roles<br>
&gt; packages and it encroaches a lot on my domain model, meaning I either<br>
&gt; have to use all of it or none of it. But maybe I have misinterpreted its<br>
&gt; design? Maybe it's better than my slogging in the code has revealed, and<br>
&gt; I should use it? Some documentation about the rationale for the<br>
&gt; abstractions chosen and how they're implemented would be nice.<br>
&gt;<br>
&gt; What I'd like to see in Aida is a greater commitment to REST and maybe<br>
&gt; XMLRPC API support (seems you're working on that one quite<br>
&gt; aggressively), more of an MVP vs MVC pattern for rendering, and perhaps<br>
&gt; support for rich web clients a la Amber (I see there is WebDAV support<br>
&gt; in Aida, so perhaps you're already intending to go that route), and<br>
&gt; better security (I really need to support HTTPS, and support API keys<br>
&gt; securely). Seaside has done a good job in its HTML API, but Aida's<br>
&gt; abstractions feel somewhat heavy (gazillions of methods). Some<br>
&gt; refactoring of that seems like it could be good.<br>
&gt;<br>
&gt; Neither framework handles layouts, look-feel, or any of the design<br>
&gt; intensive side of web development as nicely as I imagine it could be<br>
&gt; done. This could be an area for huge win in Aida, as I see you've tried<br>
&gt; to make it easy to reskin a site by supplying a new web style. However,<br>
&gt; I tried doing this with the demo app and only just mucked stuff up.<br>
&gt; Again, good documentation about this important area of implementation<br>
&gt; and some idea of what the end-goal is for it would be awesome.<br>
&gt;<br>
&gt; I'm willing to contribute but I need to get up and running and confident<br>
&gt; in what I'm doing still. It's been a bit of a ramp up. But I think I'll<br>
&gt; do well with this choice for what I need to do. I would just like to<br>
&gt; know what the future holds as I think there is still a lot of room for<br>
&gt; innovation in web development, and it doesn't all have to be heretical<br>
&gt; to be on the bleeding edge, so to speak. I'll feel better about Aida<br>
&gt; knowing that it's roadmap is a good one.<br>
&gt;<br>
&gt; - Bob<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Aida mailing list<br>
&gt; <a href="mailto:Aida <at> aidaweb.si">Aida <at> aidaweb.si</a><br>
&gt; <a href="http://lists.aidaweb.si/mailman/listinfo/aida" target="_blank">http://lists.aidaweb.si/mailman/listinfo/aida</a><br><span class="HOEnZb"><br>
--<br>
Janko Miv&scaron;ek<br>
Aida/Web<br>
Smalltalk Web Application Server<br><a href="http://www.aidaweb.si" target="_blank">http://www.aidaweb.si</a><br>
_______________________________________________<br>
Aida mailing list<br><a href="mailto:Aida <at> aidaweb.si">Aida <at> aidaweb.si</a><br><a href="http://lists.aidaweb.si/mailman/listinfo/aida" target="_blank">http://lists.aidaweb.si/mailman/listinfo/aida</a><br></span>
</blockquote>
</div>
<br>
</div>
Robert Calco | 10 Feb 17:11 2012
Picon

Re: Vision for Aida

Since I mentioned minor buggy behaviors, just another quick bug report:


In the Pharo OneClick image (I haven't seen this one in VW I don't believe), you periodically get an error that says: MessageNotUnderstood: receiver of "nextPutAll:" is nil. This is happening in ExternalWindowsOSProcess>>value:

value
"Start the external process"

| procInfo mainThread |
self isNotYetRunning ifTrue:
[procInfo := OSProcess accessor primCommand: self commandLine.
procInfo isNil
ifTrue:
[self initialStdErr nextPutAll: 'cannot execute ', 
                                   self commandLine; cr.
self exitStatus: #cannotExecuteCommandLine.
"FIXME: Close the OSPipes now, otherwise the image will 
                                 block on a read"
self closeStreams.
[self complete] fork "defer execution so OSPipes 
                                                              stay in place for now"]
    ...

Again, to a noob, this gives an impression of a weakness, in what should be an Aida strength... a built in way to run periodic/scheduled events. 

Now I know, this is probably not even your bug, but Pharo's, and apparently only on Windoze, nevertheless it's something that I have noticed and found annoying. 

- Bob
 
On Fri, Feb 10, 2012 at 3:59 PM, Robert Calco <bobcalco <at> gmail.com> wrote:
Hi Janko,

2012/2/10 Janko Mivšek <janko.mivsek <at> eranova.si>
Hi Bob,

You just inspired me to write down my vision and future plans for Aida,

:)
 
so let me start with that:

Main *Aida vision* from the start is to extend the Smalltalk philosophy,
elegance, simplicity, power to the web applications as well while
preserving all those beauties of Smalltalk.

I would really like to see Aida make coding in HTML/CSS/JavaScript a relic of the ancient past (I guess that would be Web 2.0 by now; what are we up to...4.0?).... 

I like the direction WebSharper (F#) and LiftWeb (Scala) have been going. I really am intrigued by Amber, Cappuccino, and CoffeeScript. Aida web should 'Aid' in those kinds of experiments, only with Smalltalk and some kind of clean MVP pattern applied with rigour on the server and the client side.

I like the idea behind how Seaside maintains complex state. I am not terribly thrilled with replacing, rather than embracing, the realities of HTTP... it seems to me the overhead of that strategy will only be worth it till a cleaner way to do it RESTfully emerges.
 

And to be on the *bleeding edge of web technology* with Smalltalk all
the time. Which we are. I'm most proud that initial architecture was set
good enough to be adaptable through all that time since 1996 and that we
are not stuck even now supporting the current HTML5 wave.

That is an important plus. However, I'd like to see fewer bugs than have popped up, which give it the appearance of instability. For example, even now, if you want to put the Pharo-Aida-OneClick in a bad state, just log in as admin to the demo site, click Settings -> Sites, and try to go back, or navigate anywhere else. You'll need to invoke the following magical incantations:

SwazooServer stop.
AIDASite default releaseApplicationState.
SwazooServer start.

To you that's not a big deal, you know you've got a bug there. To a new person, that makes you wonder if the framework is stable. That kind of thing.
 

And here are the plans. Short-term, long-term? Well, we'll see :)

1. *Documentation*! It seems Aida core features are stable enough now
  that we can document it and that this documentation will last for a
  while without needing to update it constantly;

Yay! :)
 

2. More *HTML5*! like FileSystem, DragDrop, Video and Audio etc etc;

Excellent.
 

3. More *realtime*, actually realtime anything, everywhere. WebSocket
  standard is now de-facto complete and in a year all browsers will
  support it. What I mean by realtime anything, everywhere? Any data
  you show everywhere on your web page will be updated in realtime,
  that is, immediately when data changes. And this will be switched on
  by default!

Good! 

4 More *client*! That is, more processing moved to web client with
 Amber Smalltalk. Here the end goal is to partition your app in
 runtime where to run. All on server as now, all on client (and
 offline), or parts on server, parts on client. Client parts are
 "emitted" to Amber Smalltalk and sent to a client for execution;

Interesting.
 

5. More *local updating* at the client. On server only data is
  updated while all dependent views are refreshed locally on client;

6. *Automatic forms building* out of domain model, with help of
  forthcoming AidaFields by Nicolas Petton;

Oh, how I long for an Aida answer to Magritte! I really love the concept.
 

7. More *relational domain model* support;

Well, how about: just some decent support for the main persistence alternatives... in-image, GLORP, GemStone, etc.. Some kind of guidance here for noobs would be most helpful. Ahem. :)
 

8. More *JavaScript libraries* supported as Aida Addons;

I think the abstractions for JavaScript and CSS are not yet refined. There is some vision gap there in both Seaside and Aida.
 

9. Aida as provider of *REST-full web services* accessible from other
  web or mobile apps

I have serious secure API needs for my applications. I feel rather insecure right now with Smalltalk vis a vis HTTPS.


10.*Cloud* support, Aida apps as both as client as service provider in
  the cloud;

I like. :)
 

11.*Aida hosting*, both free and commercial.

Would be very nice if there was more of that, yes. :)

I think a twelfth point should be *Tooling*... it needs to be much more intuitive to build sites and apps on the sites in one or more images. A secure Web Development UI would be cool. Wizards in the development image for visualizing what's where would be really helpful.

- Bob
 


Best regards
Janko



S, Robert Calco piše:
> Janko,
>
> I was wondering if you could reveal any grand plans you might have for
> the future of Aida?
>
> What I like about Aida compared to Seaside is its relative simplicity
> and portability. Seaside uses features of Smalltalk that are not really
> portable between smalltalks to do its magic (continuations and pragmas
> being the big ones that I've noticed, which prevent it from being used
> fully in Dolphin, for example).
>
> It feels to me like Aida doesn't try to reinvent too many wheels,
> meaning it's a bit more accessible to people coming from, say, Rails,
> like myself. It has relatively more steak than sizzle, whereas Seaside
> has relatively more sizzle than steak. I like my steak rare ("still
> twitching" is what I tell waitresses at restaurants), so I don't care
> about sizzle so much. That said, my favourite way to prepare steak is
> 'black and blue' -- but it takes a rather industrial-size furnace to
> cook it that way, but, working for a charity, I usually only have a
> couple matches and a little kindling to start my fire pit. ;)
>
> What I don't like about Aida is the documentation, which is a bit
> scattered by topic and somewhat stream of consciousness. Seaside has
> Aida beat hands-down in this department. There are books, well-designed
> tutorials, lots of samples, etc. It's actually very hard, if you're me,
> to ignore that big plus for Seaside.
>
> I think Aida needs a much better, much more in-depth tutorial, that
> really highlights its best parts, and suggests where it's going to get
> better over time. I am not sure I like all the parts of Aida included --
> for example, I've been reviewing the (very involved) Parties/Roles
> packages and it encroaches a lot on my domain model, meaning I either
> have to use all of it or none of it. But maybe I have misinterpreted its
> design? Maybe it's better than my slogging in the code has revealed, and
> I should use it? Some documentation about the rationale for the
> abstractions chosen and how they're implemented would be nice.
>
> What I'd like to see in Aida is a greater commitment to REST and maybe
> XMLRPC API support (seems you're working on that one quite
> aggressively), more of an MVP vs MVC pattern for rendering, and perhaps
> support for rich web clients a la Amber (I see there is WebDAV support
> in Aida, so perhaps you're already intending to go that route), and
> better security (I really need to support HTTPS, and support API keys
> securely). Seaside has done a good job in its HTML API, but Aida's
> abstractions feel somewhat heavy (gazillions of methods). Some
> refactoring of that seems like it could be good.
>
> Neither framework handles layouts, look-feel, or any of the design
> intensive side of web development as nicely as I imagine it could be
> done. This could be an area for huge win in Aida, as I see you've tried
> to make it easy to reskin a site by supplying a new web style. However,
> I tried doing this with the demo app and only just mucked stuff up.
> Again, good documentation about this important area of implementation
> and some idea of what the end-goal is for it would be awesome.
>
> I'm willing to contribute but I need to get up and running and confident
> in what I'm doing still. It's been a bit of a ramp up. But I think I'll
> do well with this choice for what I need to do. I would just like to
> know what the future holds as I think there is still a lot of room for
> innovation in web development, and it doesn't all have to be heretical
> to be on the bleeding edge, so to speak. I'll feel better about Aida
> knowing that it's roadmap is a good one.
>
> - Bob
>
>
>
>
> _______________________________________________
> Aida mailing list
> Aida <at> aidaweb.si
> http://lists.aidaweb.si/mailman/listinfo/aida

--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida


<div>
<p>Since I mentioned minor buggy behaviors, just another quick bug report:</p>
<div><br></div>
<div>In the Pharo OneClick image (I haven't seen this one in VW I don't believe), you periodically get an error that says: MessageNotUnderstood: receiver of "nextPutAll:" is nil. This is happening in ExternalWindowsOSProcess&gt;&gt;value:</div>
<div><br></div>
<div>
<div>value</div>
<div>
<span class="Apple-tab-span">	</span>"Start the external process"</div>
<div><br></div>
<div>
<span class="Apple-tab-span">	</span>| procInfo mainThread |</div>
<div>
<span class="Apple-tab-span">	</span>self isNotYetRunning ifTrue:</div>
<div>
<span class="Apple-tab-span">		</span>[procInfo := OSProcess accessor primCommand: self commandLine.</div>
<div>
<span class="Apple-tab-span">		</span>procInfo isNil</div>
<div>
<span class="Apple-tab-span">			</span>ifTrue:</div>
<div>
<span class="Apple-tab-span">				</span>[self <span>initialStdErr nextPutAll: 'cannot execute ',</span>&nbsp;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;self commandLine; cr.</div>
<div>
<span class="Apple-tab-span">				</span>self exitStatus: #cannotExecuteCommandLine.</div>
<div>
<span class="Apple-tab-span">				</span>"FIXME: Close the OSPipes now, otherwise the image will&nbsp;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;block on a read"</div>
<div>
<span class="Apple-tab-span">				</span>self closeStreams.</div>
<div>
<span class="Apple-tab-span">				</span>[self complete] fork "defer execution so OSPipes&nbsp;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; stay in place for now"]</div>&nbsp; &nbsp; ...</div>
<div><br></div>
<div>Again, to a noob, this gives an impression of a weakness, in what should be an Aida strength... a built in way to run periodic/scheduled events.&nbsp;</div>
<div><br></div>
<div>Now I know, this is probably not even your bug, but Pharo's, and apparently only on Windoze, nevertheless it's something that I have noticed and found annoying.&nbsp;</div>
<div><br></div>
<div>- Bob</div>
<div>&nbsp;<br><div class="gmail_quote">On Fri, Feb 10, 2012 at 3:59 PM, Robert Calco <span dir="ltr">&lt;<a href="mailto:bobcalco <at> gmail.com">bobcalco <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Hi Janko,<br><br><div class="gmail_quote">
<div class="im">2012/2/10 Janko Miv&scaron;ek <span dir="ltr">&lt;<a href="mailto:janko.mivsek <at> eranova.si" target="_blank">janko.mivsek <at> eranova.si</a>&gt;</span><br><blockquote class="gmail_quote">

Hi Bob,<br><br>
You just inspired me to write down my vision and future plans for Aida,<br>
</blockquote>
<div><br></div>
</div>
<div>:)</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">

so let me start with that:<br><br>
Main *Aida vision* from the start is to extend the Smalltalk philosophy,<br>
elegance, simplicity, power to the web applications as well while<br>
preserving all those beauties of Smalltalk.<br>
</blockquote>
<div><br></div>
</div>
<div>I would really like to see Aida make coding in HTML/CSS/JavaScript a relic of the ancient past (I guess that would be Web 2.0 by now; what are we up to...4.0?)....&nbsp;</div>

<div><br></div>
<div>I like the direction WebSharper (F#) and LiftWeb (Scala) have been going. I really am intrigued by Amber, Cappuccino, and CoffeeScript. Aida web should 'Aid' in those kinds of experiments, only with Smalltalk and some kind of clean MVP pattern applied with rigour on the server and the client side.</div>

<div><br></div>
<div>I like the idea behind how Seaside maintains complex state. I am not terribly thrilled with replacing, rather than embracing, the realities of HTTP... it seems to me the overhead of that strategy will only be worth it till a cleaner way to do it RESTfully emerges.</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
And to be on the *bleeding edge of web technology* with Smalltalk all<br>
the time. Which we are. I'm most proud that initial architecture was set<br>
good enough to be adaptable through all that time since 1996 and that we<br>
are not stuck even now supporting the current HTML5 wave.<br>
</blockquote>
<div><br></div>
</div>
<div>That is an important plus. However, I'd like to see fewer bugs than have popped up, which give it the appearance of instability. For example, even now, if you want to put the Pharo-Aida-OneClick in a bad state, just log in as admin to the demo site, click Settings -&gt; Sites, and try to go back, or navigate anywhere else. You'll need to invoke the following magical incantations:</div>

<div><br></div>
<div>SwazooServer stop.</div>
<div>AIDASite default releaseApplicationState.</div>
<div>SwazooServer start.</div>
<div><br></div>
<div>To you that's not a big deal, you know you've got a bug there. To a new person, that makes you wonder if the framework is stable. That kind of thing.</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
And here are the plans. Short-term, long-term? Well, we'll see :)<br><br>
1. *Documentation*! It seems Aida core features are stable enough now<br>
 &nbsp; that we can document it and that this documentation will last for a<br>
 &nbsp; while without needing to update it constantly;<br>
</blockquote>
<div><br></div>
</div>
<div>Yay! :)</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
2. More *HTML5*! like FileSystem, DragDrop, Video and Audio etc etc;<br>
</blockquote>
<div><br></div>
</div>
<div>Excellent.</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
3. More *realtime*, actually realtime anything, everywhere. WebSocket<br>
 &nbsp; standard is now de-facto complete and in a year all browsers will<br>
 &nbsp; support it. What I mean by realtime anything, everywhere? Any data<br>
 &nbsp; you show everywhere on your web page will be updated in realtime,<br>
 &nbsp; that is, immediately when data changes. And this will be switched on<br>
 &nbsp; by default!<br>
</blockquote>
<div><br></div>
</div>
<div>Good!&nbsp;</div>
<div class="im">
<blockquote class="gmail_quote">
<br>
4 More *client*! That is, more processing moved to web client with<br>
 &nbsp;Amber Smalltalk. Here the end goal is to partition your app in<br>
 &nbsp;runtime where to run. All on server as now, all on client (and<br>
 &nbsp;offline), or parts on server, parts on client. Client parts are<br>
 &nbsp;"emitted" to Amber Smalltalk and sent to a client for execution;<br>
</blockquote>
<div><br></div>
</div>
<div>Interesting.</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
5. More *local updating* at the client. On server only data is<br>
 &nbsp; updated while all dependent views are refreshed locally on client;<br><br>
6. *Automatic forms building* out of domain model, with help of<br>
 &nbsp; forthcoming AidaFields by Nicolas Petton;<br>
</blockquote>
<div><br></div>
</div>
<div>Oh, how I long for an Aida answer to Magritte! I really love the concept.</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
7. More *relational domain model* support;<br>
</blockquote>
<div><br></div>
</div>
<div>Well, how about: just some decent support for the main persistence alternatives... in-image, GLORP, GemStone, etc.. Some kind of guidance here for noobs would be most helpful. Ahem. :)</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
8. More *JavaScript libraries* supported as Aida Addons;<br>
</blockquote>
<div><br></div>
</div>
<div>I think the abstractions for JavaScript and CSS are not yet refined. There is some vision gap there in both Seaside and Aida.</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
9. Aida as provider of *REST-full web services* accessible from other<br>
 &nbsp; web or mobile apps<br>
</blockquote>
<div><br></div>
</div>
<div>I have serious secure API needs for my applications.&nbsp;I feel rather insecure right now with Smalltalk vis a vis HTTPS.</div>
<div class="im">
<div><br></div>
<blockquote class="gmail_quote">

<br>
10.*Cloud* support, Aida apps as both as client as service provider in<br>
 &nbsp; the cloud;<br>
</blockquote>
<div><br></div>
</div>
<div>I like. :)</div>
<div class="im">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
11.*Aida hosting*, both free and commercial.<br>
</blockquote>
<div><br></div>
</div>
<div>Would be very nice if there was more of that, yes. :)</div>
<div><br></div>
<div>I think a twelfth point should be *Tooling*... it needs to be much more intuitive to build sites and apps on the sites in one or more images. A secure Web Development UI would be cool. Wizards in the development image for visualizing what's where would be really helpful.</div>

<div><br></div>
<div>- Bob</div>
<div><div class="h5">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br><br>
Best regards<br>
Janko<br><br><br><br>
S, Robert Calco pi&scaron;e:<br><div><div>&gt; Janko,<br>
&gt;<br>
&gt; I was wondering if you could reveal any grand plans you might have for<br>
&gt; the future of Aida?<br>
&gt;<br>
&gt; What I like about Aida compared to Seaside is its relative simplicity<br>
&gt; and portability. Seaside uses features of Smalltalk that are not really<br>
&gt; portable between smalltalks to do its magic (continuations and pragmas<br>
&gt; being the big ones that I've noticed, which prevent it from being used<br>
&gt; fully in Dolphin, for example).<br>
&gt;<br>
&gt; It feels to me like Aida doesn't try to reinvent too many wheels,<br>
&gt; meaning it's a bit more accessible to people coming from, say, Rails,<br>
&gt; like myself. It has relatively more steak than sizzle, whereas Seaside<br>
&gt; has relatively more sizzle than steak. I like my steak rare ("still<br>
&gt; twitching" is what I tell waitresses at restaurants), so I don't care<br>
&gt; about sizzle so much. That said, my favourite way to prepare steak is<br>
&gt; 'black and blue' -- but it takes a rather industrial-size furnace to<br>
&gt; cook it that way, but, working for a charity, I usually only have a<br>
&gt; couple matches and a little kindling to start my fire pit. ;)<br>
&gt;<br>
&gt; What I don't like about Aida is the documentation, which is a bit<br>
&gt; scattered by topic and somewhat stream of consciousness. Seaside has<br>
&gt; Aida beat hands-down in this department. There are books, well-designed<br>
&gt; tutorials, lots of samples, etc. It's actually very hard, if you're me,<br>
&gt; to ignore that big plus for Seaside.<br>
&gt;<br>
&gt; I think Aida needs a much better, much more in-depth tutorial, that<br>
&gt; really highlights its best parts, and suggests where it's going to get<br>
&gt; better over time. I am not sure I like all the parts of Aida included --<br>
&gt; for example, I've been reviewing the (very involved) Parties/Roles<br>
&gt; packages and it encroaches a lot on my domain model, meaning I either<br>
&gt; have to use all of it or none of it. But maybe I have misinterpreted its<br>
&gt; design? Maybe it's better than my slogging in the code has revealed, and<br>
&gt; I should use it? Some documentation about the rationale for the<br>
&gt; abstractions chosen and how they're implemented would be nice.<br>
&gt;<br>
&gt; What I'd like to see in Aida is a greater commitment to REST and maybe<br>
&gt; XMLRPC API support (seems you're working on that one quite<br>
&gt; aggressively), more of an MVP vs MVC pattern for rendering, and perhaps<br>
&gt; support for rich web clients a la Amber (I see there is WebDAV support<br>
&gt; in Aida, so perhaps you're already intending to go that route), and<br>
&gt; better security (I really need to support HTTPS, and support API keys<br>
&gt; securely). Seaside has done a good job in its HTML API, but Aida's<br>
&gt; abstractions feel somewhat heavy (gazillions of methods). Some<br>
&gt; refactoring of that seems like it could be good.<br>
&gt;<br>
&gt; Neither framework handles layouts, look-feel, or any of the design<br>
&gt; intensive side of web development as nicely as I imagine it could be<br>
&gt; done. This could be an area for huge win in Aida, as I see you've tried<br>
&gt; to make it easy to reskin a site by supplying a new web style. However,<br>
&gt; I tried doing this with the demo app and only just mucked stuff up.<br>
&gt; Again, good documentation about this important area of implementation<br>
&gt; and some idea of what the end-goal is for it would be awesome.<br>
&gt;<br>
&gt; I'm willing to contribute but I need to get up and running and confident<br>
&gt; in what I'm doing still. It's been a bit of a ramp up. But I think I'll<br>
&gt; do well with this choice for what I need to do. I would just like to<br>
&gt; know what the future holds as I think there is still a lot of room for<br>
&gt; innovation in web development, and it doesn't all have to be heretical<br>
&gt; to be on the bleeding edge, so to speak. I'll feel better about Aida<br>
&gt; knowing that it's roadmap is a good one.<br>
&gt;<br>
&gt; - Bob<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Aida mailing list<br>
&gt; <a href="mailto:Aida <at> aidaweb.si" target="_blank">Aida <at> aidaweb.si</a><br>
&gt; <a href="http://lists.aidaweb.si/mailman/listinfo/aida" target="_blank">http://lists.aidaweb.si/mailman/listinfo/aida</a><br><span><br>
--<br>
Janko Miv&scaron;ek<br>
Aida/Web<br>
Smalltalk Web Application Server<br><a href="http://www.aidaweb.si" target="_blank">http://www.aidaweb.si</a><br>
_______________________________________________<br>
Aida mailing list<br><a href="mailto:Aida <at> aidaweb.si" target="_blank">Aida <at> aidaweb.si</a><br><a href="http://lists.aidaweb.si/mailman/listinfo/aida" target="_blank">http://lists.aidaweb.si/mailman/listinfo/aida</a><br></span>
</blockquote>
</div></div>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
Janko Mivšek | 10 Feb 19:15 2012
Picon

Tutorial, how to improve it? (was Vision for Aida)

S, Robert Calco piše:

> I think Aida needs a much better, much more in-depth tutorial, that
> really highlights its best parts, and suggests where it's going to get
> better over time. 

Ok, let we start improving documentation by improving a tutorial. So far
we have two articles:

1. Tutorial for a "traditional" Aida [1]
2. ToDo example in-depth description [2]

Tutorial has now at the bottom a link to the ToDo description.

Tutorial is probably not attractive enough for a first impression,
because it shows so called traditional web application in a sense that
there we have classical web pages and navigation between them
(graph-like control flow) but not more recent ajaxified style of
'single-page' web app development, which is shown in the ToDo example.

One solution would be to introduce another tutorial for a simple
ajaxified web app, with widgets, realtime form validation etc. then
continue with current one to shows the traditional Aida as well. and
then ToDo example description.

Any ideas, how to proceed?

Janko

[1] http://www.aidaweb.si/tutorial.html
[2] http://www.aidaweb.si/todo-description

--

-- 
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida
David Jacobs | 10 Feb 19:52 2012
Picon

Re: Tutorial, how to improve it? (was Vision for Aida)

2012/2/10 Janko Mivšek <janko.mivsek <at> eranova.si>:
> S, Robert Calco piše:
>
>> I think Aida needs a much better, much more in-depth tutorial, that
>> really highlights its best parts, and suggests where it's going to get
>> better over time.
>
> Ok, let we start improving documentation by improving a tutorial. So far
> we have two articles:
>
> 1. Tutorial for a "traditional" Aida [1]
> 2. ToDo example in-depth description [2]

Indeed, Aida could use more tutorials.

> One solution would be to introduce another tutorial for a simple
> ajaxified web app, with widgets, realtime form validation etc. then
> continue with current one to shows the traditional Aida as well. and
> then ToDo example description.
>
> Any ideas, how to proceed?

I really like RoR tutorial http://ruby.railstutorial.org/ . Maybe a
translation to Aida? The beauty of that tutorial is also how it
explains the use of TDD (or BDD), git, ... , or how things work in
Ruby, not strictly only Rails.
But ofcourse, you need to decide what your audience for an Aida
tutorial is: experienced Smalltalk-users, newcomers, ...

Kind regards,
 - david (new to Smalltalk & Aida)
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida
Robert Calco | 10 Feb 20:00 2012
Picon

Re: Tutorial, how to improve it? (was Vision for Aida)

Hi Janko,


As I have a lot of opinions about this, I'll volunteer to work on it with you. :)

1. It should implement a non-trivial data model. At least one each of a many-to-many, one-to-many, and one-to-one relationship in the domain. 

2. It should be iterative, where we start with a 'traditional' site, layer in unobtrusive JavaScript, and then get fancy with Ajax, WebSocket, etc. On the domain model side, it should first implement in-image persistence, then move onto GLORP and then GemStone as alternate back-ends when you need to run more than one image, possibly on different machines. It *must* cover deployment well. I personally can't stand when that very difficult part of correctly using a framework is 'left as an exercise for the reader'... ;)

3. It should explain the core internals and cover styling in detail. Assume you're talking to experienced engineers coming from a Rails, Symfony, Django, or Grails background. Do not assume they're seasoned Smalltalkers.

4. It should touch on things that are unique to Aida... hosting multiple sites... the way apps get layered onto sites to create systems... being able to run scheduled one-off or periodic processes in the background... really show Aida's breadth while going deep only into domain models, UI, and deployment issues.

5. It must be follow-along-as-you-go, leaving nothing really assumed and easy for someone to bookmark where they are, close their image for the night, and pick up first thing in the afternoon when they wake up... ;)

- Bob


2012/2/10 Janko Mivšek <janko.mivsek <at> eranova.si>
S, Robert Calco piše:

> I think Aida needs a much better, much more in-depth tutorial, that
> really highlights its best parts, and suggests where it's going to get
> better over time.

Ok, let we start improving documentation by improving a tutorial. So far
we have two articles:

1. Tutorial for a "traditional" Aida [1]
2. ToDo example in-depth description [2]

Tutorial has now at the bottom a link to the ToDo description.

Tutorial is probably not attractive enough for a first impression,
because it shows so called traditional web application in a sense that
there we have classical web pages and navigation between them
(graph-like control flow) but not more recent ajaxified style of
'single-page' web app development, which is shown in the ToDo example.

One solution would be to introduce another tutorial for a simple
ajaxified web app, with widgets, realtime form validation etc. then
continue with current one to shows the traditional Aida as well. and
then ToDo example description.

Any ideas, how to proceed?

Janko

[1] http://www.aidaweb.si/tutorial.html
[2] http://www.aidaweb.si/todo-description




--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida

<div>
<p>Hi Janko,</p>
<div><br></div>
<div>As I have a lot of opinions about this, I'll volunteer to work on it with you. :)</div>
<div><br></div>
<div>1. It should implement a non-trivial data model. At least one each of a many-to-many, one-to-many, and one-to-one relationship in the domain.&nbsp;</div>
<div><br></div>
<div>2. It should be iterative, where we start with a 'traditional' site, layer in unobtrusive JavaScript, and then get fancy with Ajax, WebSocket, etc. On the domain model side, it should first implement in-image persistence, then move onto GLORP and then GemStone as alternate back-ends when you need to run more than one image, possibly on different machines. It *must* cover deployment well. I personally can't stand when that very difficult part of correctly using a framework is 'left as an exercise for the reader'... ;)</div>
<div><br></div>
<div>3. It should explain the core internals and cover styling in detail. Assume you're talking to experienced engineers coming from a Rails, Symfony, Django, or Grails background. Do not assume they're seasoned Smalltalkers.</div>
<div><br></div>
<div>4. It should touch on things that are unique to Aida... hosting multiple sites... the way apps get layered onto sites to create systems... being able to run scheduled one-off or periodic processes in the background... really show Aida's breadth while going deep only into domain models, UI, and deployment issues.</div>
<div><br></div>
<div>5. It must be follow-along-as-you-go, leaving nothing really assumed and easy for someone to bookmark where they are, close their image for the night, and pick up first thing in the afternoon when they wake up... ;)</div>
<div><br></div>
<div>- Bob</div>
<div>
<br><br><div class="gmail_quote">2012/2/10 Janko Miv&scaron;ek <span dir="ltr">&lt;<a href="mailto:janko.mivsek <at> eranova.si">janko.mivsek <at> eranova.si</a>&gt;</span><br><blockquote class="gmail_quote">
S, Robert Calco pi&scaron;e:<br><br>
&gt; I think Aida needs a much better, much more in-depth tutorial, that<br>
&gt; really highlights its best parts, and suggests where it's going to get<br>
&gt; better over time.<br><br>
Ok, let we start improving documentation by improving a tutorial. So far<br>
we have two articles:<br><br>
1. Tutorial for a "traditional" Aida [1]<br>
2. ToDo example in-depth description [2]<br><br>
Tutorial has now at the bottom a link to the ToDo description.<br><br>
Tutorial is probably not attractive enough for a first impression,<br>
because it shows so called traditional web application in a sense that<br>
there we have classical web pages and navigation between them<br>
(graph-like control flow) but not more recent ajaxified style of<br>
'single-page' web app development, which is shown in the ToDo example.<br><br>
One solution would be to introduce another tutorial for a simple<br>
ajaxified web app, with widgets, realtime form validation etc. then<br>
continue with current one to shows the traditional Aida as well. and<br>
then ToDo example description.<br><br>
Any ideas, how to proceed?<br><br>
Janko<br><br>
[1] <a href="http://www.aidaweb.si/tutorial.html" target="_blank">http://www.aidaweb.si/tutorial.html</a><br>
[2] <a href="http://www.aidaweb.si/todo-description" target="_blank">http://www.aidaweb.si/todo-description</a><br><span class="HOEnZb"><br><br><br><br>
--<br>
Janko Miv&scaron;ek<br>
Aida/Web<br>
Smalltalk Web Application Server<br><a href="http://www.aidaweb.si" target="_blank">http://www.aidaweb.si</a><br>
_______________________________________________<br>
Aida mailing list<br><a href="mailto:Aida <at> aidaweb.si">Aida <at> aidaweb.si</a><br><a href="http://lists.aidaweb.si/mailman/listinfo/aida" target="_blank">http://lists.aidaweb.si/mailman/listinfo/aida</a><br></span>
</blockquote>
</div>
<br>
</div>
</div>
Janko Mivšek | 10 Feb 22:28 2012
Picon

Re: Tutorial, how to improve it?

Hi David,

Let me first welcome to the list and in the Aida world!

> I really like RoR tutorial http://ruby.railstutorial.org/ . Maybe a
> translation to Aida? The beauty of that tutorial is also how it
> explains the use of TDD (or BDD), git, ... , or how things work in
> Ruby, not strictly only Rails.
> But ofcourse, you need to decide what your audience for an Aida
> tutorial is: experienced Smalltalk-users, newcomers, ...

Wow, this tutorial is a whole book! We certainly don't have resources
for something like that but we can be inspired with the structure and
ideas of that tutorial. Like how it is gradually improving your
knowledge from chapter to chapter.

So current tutorial is too short? What is your feeling when you finish
it? Do you have some "aha" moment? Do you want more but you don't know
where to proceed?

Best regards
Janko

S, David Jacobs piše:
> 2012/2/10 Janko Mivšek <janko.mivsek <at> eranova.si>:
>> S, Robert Calco piše:
>>
>>> I think Aida needs a much better, much more in-depth tutorial, that
>>> really highlights its best parts, and suggests where it's going to get
>>> better over time.
>>
>> Ok, let we start improving documentation by improving a tutorial. So far
>> we have two articles:
>>
>> 1. Tutorial for a "traditional" Aida [1]
>> 2. ToDo example in-depth description [2]
> 
> Indeed, Aida could use more tutorials.
> 
>> One solution would be to introduce another tutorial for a simple
>> ajaxified web app, with widgets, realtime form validation etc. then
>> continue with current one to shows the traditional Aida as well. and
>> then ToDo example description.
>>
>> Any ideas, how to proceed?
> 
> I really like RoR tutorial http://ruby.railstutorial.org/ . Maybe a
> translation to Aida? The beauty of that tutorial is also how it
> explains the use of TDD (or BDD), git, ... , or how things work in
> Ruby, not strictly only Rails.
> But ofcourse, you need to decide what your audience for an Aida
> tutorial is: experienced Smalltalk-users, newcomers, ...
> 
> Kind regards,
>  - david (new to Smalltalk & Aida)
> _______________________________________________
> Aida mailing list
> Aida <at> aidaweb.si
> http://lists.aidaweb.si/mailman/listinfo/aida

--

-- 
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida
Janko Mivšek | 13 Feb 11:09 2012
Picon

Re: Tutorial, how to improve it?

Hi guys,

Current tutorial seems to let the people develop an impression (as in
this Reddit comment [1]) of "Aida as being well-suited for writing
websites, and Seaside as being well-suited for writing web applications".

This is certaily not true, Aida is using mainly in business web
applications almost from the start. Well, from the start it was
developed for our main book publisher webshop, a public website
therefore, but since then it is with few exceptions used exclusively for
web apps.

So, we need to improve a tutorial to show its strengths for building web
apps ASAP. Specially that natural transition from a classical webpage
approach to so called Single-Page web application.

Best regards
Janko

[1]
http://www.reddit.com/r/programming/comments/pjggx/vision_and_plans_for_aida_smalltalk_web_framework/

S, Janko Mivšek piše:
> Hi David,
> 
> Let me first welcome to the list and in the Aida world!
> 
>> I really like RoR tutorial http://ruby.railstutorial.org/ . Maybe a
>> translation to Aida? The beauty of that tutorial is also how it
>> explains the use of TDD (or BDD), git, ... , or how things work in
>> Ruby, not strictly only Rails.
>> But ofcourse, you need to decide what your audience for an Aida
>> tutorial is: experienced Smalltalk-users, newcomers, ...
> 
> Wow, this tutorial is a whole book! We certainly don't have resources
> for something like that but we can be inspired with the structure and
> ideas of that tutorial. Like how it is gradually improving your
> knowledge from chapter to chapter.
> 
> So current tutorial is too short? What is your feeling when you finish
> it? Do you have some "aha" moment? Do you want more but you don't know
> where to proceed?
> 
> Best regards
> Janko
> 
> S, David Jacobs piše:
>> 2012/2/10 Janko Mivšek <janko.mivsek <at> eranova.si>:
>>> S, Robert Calco piše:
>>>
>>>> I think Aida needs a much better, much more in-depth tutorial, that
>>>> really highlights its best parts, and suggests where it's going to get
>>>> better over time.
>>>
>>> Ok, let we start improving documentation by improving a tutorial. So far
>>> we have two articles:
>>>
>>> 1. Tutorial for a "traditional" Aida [1]
>>> 2. ToDo example in-depth description [2]
>>
>> Indeed, Aida could use more tutorials.
>>
>>> One solution would be to introduce another tutorial for a simple
>>> ajaxified web app, with widgets, realtime form validation etc. then
>>> continue with current one to shows the traditional Aida as well. and
>>> then ToDo example description.
>>>
>>> Any ideas, how to proceed?
>>
>> I really like RoR tutorial http://ruby.railstutorial.org/ . Maybe a
>> translation to Aida? The beauty of that tutorial is also how it
>> explains the use of TDD (or BDD), git, ... , or how things work in
>> Ruby, not strictly only Rails.
>> But ofcourse, you need to decide what your audience for an Aida
>> tutorial is: experienced Smalltalk-users, newcomers, ...
>>
>> Kind regards,
>>  - david (new to Smalltalk & Aida)
>> _______________________________________________
>> Aida mailing list
>> Aida <at> aidaweb.si
>> http://lists.aidaweb.si/mailman/listinfo/aida
> 

--

-- 
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida
Robert Calco | 13 Feb 12:01 2012
Picon

Re: Tutorial, how to improve it?

Janko,



2012/2/13 Janko Mivšek <janko.mivsek <at> eranova.si>
Hi guys,

Current tutorial seems to let the people develop an impression (as in
this Reddit comment [1]) of "Aida as being well-suited for writing
websites, and Seaside as being well-suited for writing web applications".

This is certaily not true, Aida is using mainly in business web
applications almost from the start. Well, from the start it was
developed for our main book publisher webshop, a public website
therefore, but since then it is with few exceptions used exclusively for
web apps.

So, we need to improve a tutorial to show its strengths for building web
apps ASAP. Specially that natural transition from a classical webpage
approach to so called Single-Page web application.

I think that Aida's core abstractions -- Sites, Applications, Widgets -- lends to the perception. 'Application' in Aida refers (somewhat awkwardly, IMHO) to VC combinations in the MVC triad. To me, V+C = Component and (1...n Components = Application). 

In other words, it is not intuitive to a noob that once you have a site that you layer your domain on it with as many applications as you have domain objects (roughly). I think this is perhaps where the perception comes from.

On a purely aesthetic level I really like Seaside's terminology, which is internally consistent with its stated goals. I probably would have gone with Seaside if they did not require special VM sauce to make a key part of the value proposition of the framework work (i.e., continuations). 

Really what Aida is trying to do (correct me if I'm wrong) is to let the developers actually define the semantics for themselves. A site is a root URL, an application is a chunk of functionality available at a site, and widgets are complex elements that are grouped for functional reuse within 'applications.' So, actually, Aida is trying not to impose very many constraints on how the developer organizes his/her design.

This is why a good tutorial that explains the rational for each design choice and the resulting cleaner, simpler implementation is critical if Aida is going to shake its perception as 'good for sites but not applications.'

I also think that Seaside directly addresses a real developer pain with a clean -- albeit not entirely portable -- solution. I have always *hated* building web apps because of the statelessness of HTTP. Seaside makes it easy to code in a way that the logic of a workflow is self-evident in the code, at a cost that seems not too bad when the one thing managers in the world care about most is time-to-market. That's the big whiz-bang of Seaside as I see it. They effectively created a development environment that thoroughly shields the developer from the most painful aspect of working in HTTP.

Aida should come up with a way to deal with the problems of web development that delivers similar (if not identical) value, only without the not-very-portable black magic involved in Seaside's implementation. If this exists already in Aida, please enlighten me! 

Again, a tutorial needs to address the pain of web development and how Aida removes it, not just show off features.

The other pain area that I don't think either framework deals with well yet is styling, layouts, look feel and JavaScript integration. If you're coming from a template based web development paradigm, nothing makes you feel woozier and less confident than the manner in which both frameworks deal with that. (Well, not counting the questions of RDMBS vs OODMS, in-memory persistence vs. ...etc.)

At least, I have not found that aspect to be as intuitive as it could be.

- Bob 

Best regards
Janko

[1]
http://www.reddit.com/r/programming/comments/pjggx/vision_and_plans_for_aida_smalltalk_web_framework/



<div>
<p>Janko,</p>
<div><br></div>
<div>
<br><div class="gmail_quote">2012/2/13 Janko Miv&scaron;ek <span dir="ltr">&lt;<a href="mailto:janko.mivsek <at> eranova.si">janko.mivsek <at> eranova.si</a>&gt;</span><br><blockquote class="gmail_quote">
Hi guys,<br><br>
Current tutorial seems to let the people develop an impression (as in<br>
this Reddit comment [1]) of "Aida as being well-suited for writing<br>
websites, and Seaside as being well-suited for writing web applications".<br><br>
This is certaily not true, Aida is using mainly in business web<br>
applications almost from the start. Well, from the start it was<br>
developed for our main book publisher webshop, a public website<br>
therefore, but since then it is with few exceptions used exclusively for<br>
web apps.<br><br>
So, we need to improve a tutorial to show its strengths for building web<br>
apps ASAP. Specially that natural transition from a classical webpage<br>
approach to so called Single-Page web application.<br>
</blockquote>
<div><br></div>
<div>I think that Aida's core abstractions -- Sites, Applications, Widgets -- lends to the perception. 'Application' in Aida refers&nbsp;(somewhat awkwardly, IMHO)&nbsp;to&nbsp;VC combinations in the MVC triad. To me, V+C = Component and (1...n Components = Application).&nbsp;</div>
<div><br></div>
<div>In other words, it is not intuitive to a noob that once you have a site that you layer your domain on it with as many applications as you have domain objects (roughly). I think this is perhaps where the perception comes from.</div>
<div><br></div>
<div>On a purely aesthetic level I really like Seaside's terminology, which is internally consistent with its stated goals. I probably would have gone with Seaside if they did not require special VM sauce to make a key part of the value proposition of the framework work (i.e., continuations).&nbsp;<br><br>Really what Aida is trying to do (correct me if I'm wrong) is to let the developers actually define the semantics for themselves. A site is a root URL, an application is a chunk of functionality available at a site, and widgets are complex elements that are grouped for functional reuse within 'applications.' So, actually, Aida is trying not to impose very many constraints on how the developer organizes his/her design.</div>
<div><br></div>
<div>This is why a good tutorial that explains the rational for each design choice and the resulting cleaner, simpler implementation is critical if Aida is going to shake its perception as 'good for sites but not applications.'</div>
<div><br></div>
<div>I also think that Seaside directly addresses a real developer pain with a clean -- albeit not entirely portable -- solution. I have always *hated* building web apps because of the statelessness of HTTP. Seaside makes it easy to code in a way that the logic of a workflow is self-evident in the code, at a cost that seems not too bad when the one thing managers in the world care about most is time-to-market. That's the big whiz-bang of Seaside as I see it. They effectively created a development environment that thoroughly shields the developer from the most painful aspect of working in HTTP.</div>
<div><br></div>
<div>Aida should come up with a way to deal with the problems of web development that delivers similar (if not identical) value, only without the not-very-portable black magic involved in Seaside's implementation. If this exists already in Aida, please enlighten me!&nbsp;</div>
<div><br></div>
<div>Again, a tutorial needs to address the pain of web development and how Aida removes it, not just show off features.</div>
<div><br></div>
<div>The other pain area that I don't think either framework deals with well yet is styling, layouts, look feel and JavaScript integration. If you're coming from a template based web development paradigm, nothing makes you feel woozier and less confident than the manner in which both frameworks deal with that. (Well, not counting the questions of RDMBS vs OODMS, in-memory persistence vs. ...etc.)</div>
<div><br></div>
<div>At least, I have not found that aspect to be as intuitive as it could be.</div>
<div><br></div>
<div>- Bob&nbsp;</div>
<blockquote class="gmail_quote">

<br>
Best regards<br>
Janko<br><br>
[1]<br><a href="http://www.reddit.com/r/programming/comments/pjggx/vision_and_plans_for_aida_smalltalk_web_framework/" target="_blank">http://www.reddit.com/r/programming/comments/pjggx/vision_and_plans_for_aida_smalltalk_web_framework/</a><br><br><br>
</blockquote>
</div>
<br>
</div>
</div>
Robert Calco | 13 Feb 12:10 2012
Picon

Re: Tutorial, how to improve it?

Let me clarify one point:

On Mon, Feb 13, 2012 at 11:01 AM, Robert Calco <bobcalco <at> gmail.com> wrote:


The other pain area that I don't think either framework deals with well yet is styling, layouts, look feel and JavaScript integration. If you're coming from a template based web development paradigm, nothing makes you feel woozier and less confident than the manner in which both frameworks deal with that. (Well, not counting the questions of RDMBS vs OODMS, in-memory persistence vs. ...etc.)

At least, I have not found that aspect to be as intuitive as it could be.

What I mean to say is: Neither are yet really offering innovation that makes styling applications as a task in the development cycle more intuitive. 

Most web designers are going to give me PSDs or gobs of horribly written HTML with a bunch of graphics, and how I translate that to templates in Rails is pretty straightforward, but how I do that in Seaside or Aida in a way that saves me time, I do not yet see. Could be just me, though. :)

- Bob
 

- Bob 

<div>
<p>Let me clarify one point:<br><br></p>
<div class="gmail_quote">On Mon, Feb 13, 2012 at 11:01 AM, Robert Calco <span dir="ltr">&lt;<a href="mailto:bobcalco <at> gmail.com">bobcalco <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<br><div><div class="gmail_quote">
<div><br></div>
<div>The other pain area that I don't think either framework deals with well yet is styling, layouts, look feel and JavaScript integration. If you're coming from a template based web development paradigm, nothing makes you feel woozier and less confident than the manner in which both frameworks deal with that. (Well, not counting the questions of RDMBS vs OODMS, in-memory persistence vs. ...etc.)</div>

<div><br></div>
<div>At least, I have not found that aspect to be as intuitive as it could be.</div>
</div></div>
</blockquote>
<div><br></div>
<div>What I mean to say is: Neither are yet really offering innovation that makes styling applications as a task in the development cycle more intuitive.&nbsp;</div>
<div><br></div>
<div>Most web designers are going to give me PSDs or gobs of horribly written HTML with a bunch of graphics, and how I translate that to templates in Rails is pretty straightforward, but how I do that in Seaside or Aida in a way that saves me time, I do not yet see. Could be just me, though. :)</div>
<div><br></div>
<div>- Bob</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div><div class="gmail_quote">
<div><br></div>
<div>- Bob&nbsp;</div>
<div class="im">
<blockquote class="gmail_quote"><br></blockquote>
</div>
</div></div></blockquote>
</div>
</div>

Gmane