Sasha, can you forward this to to juris, and ask him to subscribe to the
acf mailing list...

OK with me. MVC is overloaded, and I think the acf version of "mvc" is
is not quite what people think "mvc" should be.

ACF is /not/ OOP. If OOF concepts move acf forward, fine. But OOP is
just a religion I don't believe in. I'm not opposed to using OOP
concepts, but they should contribute to acf, not define it.

ACF is /not/ MVC. Personally, its been a good definition: Model is the
thing that [reads|edits] a config file/system config. Controller is
something that translates a [model object] into something that [I as a
user] care about. View is something that presents whatever the
controller understands into something that I [as a human] can understand.
If using PAC instead of MVC moves people away from the "MVC religion"
toward the "hey...let's all just move this forward" type of thinking...
I'm all for it. PAC it is... in fact, how about we call it BEJ. BEJ is
my sister's initials, and stands for Beth Eden Jenness. (which means
nothing in context) Perhaps that will help people understand. :-)

[Its just that MVC is easier to say and comprehend than BEJ... anyone
else with me?]

ACF is /not/ web based. The client can be a CLI or GUI. The
"controller" - E in the above scenario can't determine how the output is
presented. It just determines what the output widget ["view" in mvc
terms, "J" in BEJ terms] has available to display.

ACF is /not/ user driven. The ACF stance should be: the web client is
Nangel (or worse) using ncat trying to hack the system. *nothing* the
client gives us should be trusted. The client may ask us to do certain
things via http, but ACF decides to do those things, not the web client.
The web client can only make *requests*, even with POSTs. ACF can
decline any request, for any reason.

Natanael Copa wrote:
> Hi,
>
> I talked with Juris re mvc. He had done some reading and sent me an
> interesting link and said: "what we are doing looks more like PAC than
> MVC to me"
>
> http://en.wikipedia.org/wiki/Presentation-abstraction-control>
> We talked also about AJAX. I think it was an interesting discussion.
>
> You sent me a doc about template engines some time ago. I couldnt find
> it, but I think that would be good reading for Juris. It explained alot
> about how you think.
>
> Could you please send a copy to him?
>
> For your reference, here is the IRC session:
>
> <juris> good morning?
> * juris has mvc questions
> <ncopa> hi
> <juris> hi
> http://www.dossier-andreas.net/software_architecture/mvc.html> how exactly does mvc work in the coming acf?
> <ncopa> the view is a html generator
> the model wil be the code that actually do stuff
> the controller is the event dispatcher
> reacts to http GET/POST actions
> for example
> the user triggers an event. Lets say "set hostname to 'Destert'"
> Nathans mvc stuff, will find what module to load
> and handle over the event to the alpine-baselayout/hostname controller
> <juris> [nod]
> <ncopa> whilc will use the alpine-baselayout/hostname model
> to actually set the hostname
> <juris> does view takes information directly from model (as per link
> above)?
> <ncopa> in the acf, i dont believe so
> i believe the vire gets everythign via the controller
> <juris> http://en.wikipedia.org/wiki/Presentation-abstraction-control> is there some generic protocol for model? how controller accesses it?
> <ncopa> just function calls
> an unwritten api
> ;)
> <juris> shudder... sounds like in books on evolution
> <ncopa> lol
> PAC looks interesting
> and i wonder if thats what nathan is tryting to do
> but...
> we dont use multithreading
> <juris> it looks closer to mvc.lua than what I've read about MVC
> <ncopa> yes
> i agree
> <juris> suppose my favorite case of viewing large log file
> how view gets that data?
> <ncopa> ...which i remeber nathan saying:
> "this is a special case where mvc is not a good solution"
> something lke that
> however
> do you want to "browse" a logfile, or download it to the broweser?
> (or to a file)
> <juris> as I understand MVC: view pulls data directly out of model, and
> it is efficient and neat. And controller is needed only for "browsing"
> <ncopa> sounds correct to me
> nathan sent me a doc some time ago
> on template engines
> <juris> so for model to be reusable, there has to be some protocol how
> to access data
> <ncopa> ...or documented api
> <juris> also, view subscribes to content change notifications, or else
> polls model (tail -F style).
> <ncopa> the doc he sent me explained alot to me why he did what he did
> in his first version
> and how he was thinking
> <juris> I'd love to see it
> if it's not secret
> <ncopa> no no
> i'll see if i can find it
> <juris> because I'm having semantic hallucinations reading this mvc
> completely different question: what does <? local view = ... ?> do in
> -view file?
> <ncopa> it read parameters
> like: view = argv[1]
> like: view = argv[...]
> well.. this mvc
> like i see it
> <juris> helloworld-controller uses haserl.loadfile to open view
> that's a black box for me
> <ncopa> btw.. i spent one week trying to grasp this mvc concept
> and when i thought i understood it, i thought the old implementation
> was wrong
> and protested: "this is not MVC"
> <juris> is it now?
> <ncopa> (the controller was building the web pages)
> i dont know... :D
> then Nathan got disapointed
> and disencouraged
> but, that was probably not my fault only
> there was lots of things going on there in US
> so he started over
> basicly,
> <juris> I don't exactly care whether it is MVC or not, I want to
> understand how it will work :-)
> <ncopa> never ever do any program login in the view
> * never ever do any program login in the view
> <juris> ?
> <ncopa> * the controller should react to events only (not build the page
> layout or do logic)
> * the model does all the logic
> <juris> those * lines make a lot of sense
> model is the API/library thing.
> <ncopa> yes
> <juris> C + V is the UI thing
> <ncopa> yes
> <juris> but there is nothing interactive, so just merge view and
> controller
> it becomes super simple
> <ncopa> except, that we want a html template with no programming logic
> what nathan calls a "view"
> so we can "hire" a webdesigner
> to do the layout
> <juris> yep, and that is how he gets everyone confused
> because it's not the MVC view
> <ncopa> its kind of a view
> the web page is a way to present the result
> <juris> What if Sasha whats AJAX?
> * ncopa wants ajax too
> <ncopa> that when things start to get complicated
> <juris> persistent server process?
> <ncopa> because, suddenly, you have a gUI
> <juris> and MVC
> <ncopa> in the browser
> you could do the M and V in browser
> and the model is the server
> <juris> <bulb> yes!
> <ncopa> I think that would be cleaner
> <juris> but browser page would become very bloaty
> no lynx :(
> <ncopa> like all other AJAX apps
> true
> but the managers would love it
> because its polish
> <juris> true
> <ncopa> its cute
> but... thats another discussion actually
> question is do we *need* ajax
> lets say we do ajax
> then we have a GUI in webbrowser
> and a app running on server
> the app on server is the "model", right
> <juris> yes
> <ncopa> now.. to make even more confusing...
> when you build the server app, you could to it mvc internally
> user request (http request from web browser)
> is taken care of the server "controller"
> lts say: "set hostname"
> it loads alpine-base/hostname
> <juris> that again sounds like PAC on wikipedia
> <ncopa> and executes "set()"
> but instead of loading the html "view"
> it loads an xml "view"
> and returns xml code instead of html code
> and the webbrowser gets back its xml stuff and is happy
> * juris run eat
> <ncopa> Yes you are right it looks lie PAC
> ok
> thanks for discussio
> <juris> thanks!
>
>
>
Received on Mon Jan 08 2007 - 00:29:58 GMT