CodeIgniter Prototype (WAS: PFSense Logo to print)
-
Maybe it would be cool if we're allowed to put a small "powered by pfSense" logo or something… dunno... I'd like to put a tribute to pfSense on pre-installed boxes.
Speaking of rebranding the GUI, do you guys have any immediate plans on making the code use a framework such as CodeIgniter? =)
[ simon.cpu ]
-
Speaking of rebranding the GUI, do you guys have any immediate plans on making the code use a framework such as CodeIgniter? =)
I am working on a CodeIgniter prototype. But what is needed are different XML based models instead of SQL based models for example. That way you would be able to persist to an XML file as well.
Regards
Daniel S. Haischt -
Maybe simon cpu could team up with you on this project?
-
I'd gladly team up with you guys. pfSense really needs to have a solid framework in place. =)
[ simon.cpu ]
-
I think an initial step would be to port the pfSense webgui to codeigniter without any functionality. That way we could upload it to pfsense.com as a webgui dummy.
Such a dummy was requested in the past to demonstrate how the pfSense webgui may look like without the need to actually install pfSense.
What do you think?
Cheers
Daniel S. Haischt -
Such a dummy was requested in the past to demonstrate how the pfSense webgui may look like without the need to actually install pfSense.
Yep, it was me requesting such a feature as live demo ;D
-
I think an initial step would be to port the pfSense webgui to codeigniter without any functionality. That way we could upload it to pfsense.com as a webgui dummy.
Such a dummy was requested in the past to demonstrate how the pfSense webgui may look like without the need to actually install pfSense.
What do you think?
Cheers
Daniel S. HaischtI've explored and created a draft architecture (well, sort of) using CodeIgniter as the back-end and DHTML OpenLaszlo as the front-end. The design is for the back-end and front-end to communicate via ReST. Basically, I was planning to implement the Controller and Model in CodeIgniter and let the View be taken care of by OpenLaszlo*.
My initial plan was to let them communicate either via SOAP or XML-RPC, but after further reading, I found out that OL needs Java (yikes!) for those functionalities to be available.
We may have a slightly different agenda here, but I am nevertheless willing to implement a non-OpenLaszlo View for the dummy WebGUI in case you guys don't want OpenLaszlo. I am more interested with the Controller and Model though. :D
[ simon.cpu ]
- Stand-alone (i.e., pre-compiled) deployment only, without the bloated Java presentation server. For more info, please check out www.openlaszlo.org
-
Java is definitely not the way to go ;D
-
Yepp… I'll only use OpenLaszlo for generating DHTML code though.
BTW, is it OK if you'll make your prototype available? I'll start filling in the missing pieces, such as XML-based models.
[ simon.cpu ]
-
Could you split the topic and move it to a new thread? We are getting a bit off topic here.
-
Even if you are using OL just because of its DHTML GUI, I have my duobts whether the DHTML code of OL is very mature because OL was initially Adobe Flash based and the DHTML codebase was introduced in 2006 IIRC.
Beside that there are existing DHTML GUI frameworks which are re-using Prototype+Scriptaculous. See: http://extjs.com/
Cheers
Daniel S. Haischt -
Indeed, OL may or may not be mature, but its XML-based syntax is quite attractive. :D
The beauty with a solid framework in place is that we can use whatever we want in our UI– OpenLaszlo, Prototype+Scriptaculous, or even CLI-- it's really up to us.
Also, I think it would be cool for us to use ReST architecture[1][2]. CodeIgniter fits perfectly to ReST. Although CodeIgniter is designed so that we can use the Model-View-Controller (MVC) paradigm, it does not require us to use Views, nor does it require us to let our output be in pure HTML. Basically, we let:
–------------------+------------------------- ReST | CodeIgniter --------------------+------------------------- Resources (URI) | Controller invocation Representation | XML response --------------------+-------------------------Coool... ;D
[ simon.cpu ]
[1] http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html?page=1
[2] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm -
Regarding REST …
-
That subject was part of my master thesis, so I am well informed ;D
-
Please use REST (it's an acronym) to not confuse people. If referring to ReST people sometimes mean restructured text.
-
Is CodeIgniter supporting restful web services or just XML based web services like SOAP or XML-RPC based web services?
Cheers
Daniel S. Haischt -
-
Regarding representing GUI elements as XML…
pfSense is already following that approach. Tho the XML used by pfSense to represent a GUI isn't correct XML. Thus if using a validating XML parser, the parser would spit out tons of error messages.
So the goal is to ...
-
Define an XML schema that is XML conform (i.e. it validates)
-
A schema can be implemented using a DTD, XML schema or RelaxNG
-
Any of the above schema types requires to use libxml2 instead of expat
-
Create over time different views where each view outputs specific GUIs such as XHTML based DHTML, simple XHTML without JavaScript that can be rendered by a text browser or even views that are able to generate ncurses or similar console GUIs
Please read: http://wiki.pfsense.com/wikka.php?wakka=GoogleSoCIdeas. There I described some of the above ideas a little further.
And 'no' pfSense is not participating in Google's SoC ;)
Cheers
Daniel S. Haischt -
-
ReST or REST whatever… hehehe. Oki, REST that is. ;D
I'm not really sure if CodeIgniter has a built-in support for RESTful web services, but we may be able to design our architecture so that it will be as RESTful as the CI framework would allow.
I've been googling for info, and I found out that we can't really use the four HTTP verbs for our design. We can use GET for retrieving and POST for adding, updating, and deleting data; however, PUT and DELETE isn't really practical, because as far as I know, PHP (as of version 5) doesn't yet support $_PUT and $_DELETE. Although this can be solved by using JavaScript at the client side and by inspecting $_SERVER['REQUEST_METHOD'] at the server side, this is at best a kludgey solution. I would opt for the simplest and cleanest solution– using GET for reading and POST for writing.
With regards to the XML schema, I'll google for more info about that since I'm currently not that well-versed with XML. ;D
[ simon.cpu ]
-
Hi,
I did a research regarding PHP-based REST framweworks. Cause I am at work and thus do not have access to my bookmarks I won't be able to provide a link. I'll try to paste a link ASAP…
What I found so far:
http://tonic.sourceforge.net/docs/
http://wiki.jonnay.net/bunny/meditation/meditation (from 2006!)
http://giantrobots.thoughtbot.com/2007/4/2/jester-javascriptian-rest
http://www.csscripting.com/wiki/index.php?title=Freja (MVC related)Regards
Daniel S. Haischt