Artful Code

Started by kanen, August 16, 2011, 01:32:03 PM

Previous topic - Next topic

kanen

I have taken over maintenance and coding for all the Artful Code modules and plan some pretty significant updates to them over the next months.



The new location is at http://www.scruffythinking.com/">//http://www.ScruffyThinking.com/ under "Artful Code" heading.



The project has been permanently moved to ScruffyThinking and to github.



Please update your links accordingly.
. Kanen Flowers http://kanen.me[/url] .

cormullion

#1
Cool. jeff did lots of good things with newLisp and it's good to see his work kept alive...



Next: how about taking over Dragonfly?

kanen

#2
My gawd. I'd love to.



I use web.lsp and Dragonfly nearly every single day in my coding work. I'd love to merge parts of Dragonfly into a new project and add parts of Artful Web.



We need a canonical, updated version of a web framework for newLisp. :)
. Kanen Flowers http://kanen.me[/url] .

joejoe

#3
Im all for dragonfly and its modern continuance.



Both projects mentioned are exceptional and thanks to all for keeping them alive!

Lutz

#4
links are also added / updated here: http://www.newlisp.org/modules/">http://www.newlisp.org/modules/

cormullion

#5
The one problem I had with Dragonfly is that any updates would overwrite your customisations. There should probably be a way of keeping your plugins and config files separate from the system plugins, so that you easily update one without affecting the other.

hilti

#6
Quote from: "cormullion"The one problem I had with Dragonfly is that any updates would overwrite your customisations. There should probably be a way of keeping your plugins and config files separate from the system plugins, so that you easily update one without affecting the other.


I think we should develop an extensible micro-framework for newLISP. It should provide just some basic routing, views and error handling. This way nearly everything might plugged into it.
--()o Dragonfly web framework for newLISP

http://dragonfly.apptruck.de\">http://dragonfly.apptruck.de

hilti

#7
Quote from: "joejoe"Im all for dragonfly and its modern continuance.



Both projects mentioned are exceptional and thanks to all for keeping them alive!


Thanks joejoe.



Maybe Greg and I should start a pledge to buy some time for making Dragonfly one of the best available newLISP web frameworks ;-)
--()o Dragonfly web framework for newLISP

http://dragonfly.apptruck.de\">http://dragonfly.apptruck.de

joejoe

#8
I concur w/ cormullion that core upgrades to dfly should be separate from customizations.



Drupal does a pretty good job with this.

http://api.drupal.org/api/drupal">http://api.drupal.org/api/drupal



See diagrams:

http://www.google.com/search?tbm=isch&hl=en&source=hp&q=drupal+diagram+architecture&btnG=Search+Images&gbv=2&biw=1400&bih=852">http://www.google.com/search?tbm=isch&h ... 00&bih=852">http://www.google.com/search?tbm=isch&hl=en&source=hp&q=drupal+diagram+architecture&btnG=Search+Images&gbv=2&biw=1400&bih=852



And if it could stay database free, it might just live on forever.



;0)

kanen

#9
I love Dragonfly. I use it every single day.



Having said that, the framework is heavier than I would want and has a bit of a learning curve for normal users.



In a perfect world, I can imagine a single module which acts as a kind of preprocessor for all web-based (and .cgi) interactions in the system. The inclusion of a complex framework without persistent information storage and retrieval is an issue.



Imagine, then;



1. A lightweight, declarative load (i.e. "web.lsp") at the start of a .cgi or .html file.

2. Persistence. You can set and maintain variables throughout a session.

3. Speed.

4. HTML as an option, not as a default.



I do not like embedding newLisp into HTML pages. I believe having a dynamic page generated, ala JavaScript or similar languages, is a better choice. The displayed HTML should be the result of something programmatic, not the conflation of HTML and newLisp in an HTML-like file.



In this way, if you learn newLisp, you can abstract yourself from HTML, tables, JavaScript and all the other ugliness that comes with figuring out the variety of HTML (through HTML5) standards.



I've done this for my work. I have a combination of Dragonfly, Artful Code and some custom work which allows me to make a statement like:



(Web:Begin "My Web Page")  ; title
(Web:GetUserInfo)   ; cookie, if exists
(Web:Heading true)
(Web:SubHeading (Web:Table "name" "value" "name" "value"))
(Web:End)


This gives me a beautifully rendered CSS-aware titled, collapsable heading and a body with two name/value pairs in a Table.



Obviously, I am still working out the details (and there are many more options I haven't shared), but directionally, this is where I am heading.



P.S. I've included an example, with Hover Over Help, input fields and the Heading and Table directives. All generated using the framework I've mentioned above. Every field changes color on Hover Over, as do the top navigation items and the buttons. All as part of the default (easily modified) CSS, which is read by the framework on load. :)
. Kanen Flowers http://kanen.me[/url] .

jazper

#10
I have been struggling a little with Dragonfly, partly because I am new to web writing, and partly for some of the reasons mentioned:  "...heavier than I would want and has a bit of a learning curve for normal users".  About  "heavier than I would want" - Dragonfly, as it is, doesn't strike me as particularly heavy - but "has a bit of a learning curve for normal users" is even more true of me, a previous-non-creator of web code.  



Things like Joomla & Drupal are as heavy as lead to me: I get tired just looking at them.  I have friends who love them & swear by them, & normally follow their descriptions of websites created in them with the words
QuoteLook, I'm not very proud of them, but they work
I can't knock that, because I haven't got my web site going yet!



Even though I am still wading through Dragonfly source, I kind of love it for its footprint, & that it is written in newlisp.  The cgi-listener approach was new to me, too.  



What caught my eye in your post, though, was "a dynamic page generated, ala JavaScript or similar languages, is a better choice. The displayed HTML should be the result of something programmatic".  This is about what I have been cracking my head to get right.  



Kanen, I think you will get there light years before me, so I can't wait to get a snifter of how you went about the example code & attachment you sent.  Very commendable approach, & very, very interesting.

TedWalther

#11
Kanen, what do you think of adapting HAML/YAML for this purpose?  I noticed earlier that Dragonfly seemed to be missing it.  It works well for the Ruby guys.  Dragonfly is close enough to Ruby that I automatically assumed it was a drop-in replacement for Ruby on Rails.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence.  Nine months later, they left with a baby named newLISP.  The women of the ivory towers wept and wailed.  \"Abomination!\" they cried.

denis

#12
Wow, I like this discussion! Last months I touched Ruby on Rails and Django, but now I am thinking more and more about to come back to my idea of "lispization" and finally try to do something with that.

What I would say about HAML... Why not to go further and think on content that our browser gets from the server not as the page with header, title, body and footer but something more diverse and abstract? After all page metaphor appeared when internet was a bunch of text files with pictures tied together by hyperlinks. Yes, just like pages in the book or magazine, but not linearly ordered. Why should we limit ourselves by this metaphor only? In many cases I like more to see the content I get, like GUI layout, where each element/block acts separately. Then it is not so much about titles and paragraphs, tags and texts, as for something about blocks layout description, and description of interrelations of the blocks. Maybe there is also some third and fourth paradygm... Not only book's page. ...While HAML still is thinking in a page way.