|
formatting style of the engine parts (perl)
|
| Author |
Message |
gOOvER
Documentation Team
  
Posts: 1,532
Group: Docu Team
Joined: Jul 2007
Status:
Online
Reputation: 13
|
RE: formatting style of the engine parts (perl)
I think this i a good idea. Maybe ephiegenie can open you your own branch.
OS : Debian 4.0 Etch 64bit
ispCP Version : 1.0.0 r1335 - 27.08.08 (NightlyBuild)
Activated : AWStats dynamic
Mods : update via NightlyUpdateScript
!!! NO SUPPORT VIA PM OR EMAIL !!!
|
|
| 05-11-2008 08:25 PM |
|
 |
Tseng
Junior Member

Posts: 20
Group: Registered
Joined: Apr 2008
Status:
Offline
Reputation: 0
|
RE: formatting style of the engine parts (perl)
Just think about mobile devices. I am ofter on the move and I have my laptop with me most of the time. However, being able to check the server with a phone or trough a text based browser (as when using ssh over umts with a nokia e90, or an universal ppc) is a huge plus for me. Projects like gplhost support it out of the box.
So... ajax is good but might be a problem on handhelds and being able to administer without requiring a notebook will be a requirement a few years from now.
Regarding coding standard: PEAR coding standard is what I was after too. It's very reasonable and compact, hence readable. php should look the same imho.
ispcomm.
Then maybe we should also create a mobile version? If the PHP code is clean and well structured, then it shouldn't be a big problem. It's just a matter of a good templating engine. AJAX is nice, but not very well supported on mobile devices, so it should be possible to disable it.
I think this i a good idea. Maybe ephiegenie can open you your own branch.
I think that would be great.
This post was last modified: 05-11-2008 08:45 PM by Tseng.
|
|
| 05-11-2008 08:44 PM |
|
 |
Cube
Documentation Team
  
Posts: 660
Group: Docu Team
Joined: Apr 2007
Status:
Offline
Reputation: 8
|
RE: formatting style of the engine parts (perl)
Firstly if AJAX is well done there is always an automatic fallback to traditional methods. Secondly in a few years mobile devices will support JavaScript/AJAX without problems. But perhaps a framework would be nice.
A separate mobile version is not needed because we can offer mobile devices a handheld-stylesheet (media="handheld"), which formats the site the right way.
|
|
| 05-11-2008 10:30 PM |
|
 |
Tseng
Junior Member

Posts: 20
Group: Registered
Joined: Apr 2008
Status:
Offline
Reputation: 0
|
RE: formatting style of the engine parts (perl)
I'm actually planning a framework using PEAR and a MVC structure.
|
|
| 05-11-2008 11:05 PM |
|
 |
RatS
The Project's Fire Worker
     
Posts: 684
Group: Super Moderators
Joined: Oct 2006
Status:
Offline
Reputation: 18
|
RE: formatting style of the engine parts (perl)
okay; here we go:
I thought about using PEAR-Standard with small changes (look at my PHP-Guideline). It would be great if someone would post the PERL-guideline, I will adapt it and than you can start coding. I try to contact Malte for some svn-accounts; however, I don't know, if I reach him today or tomorrow.
|
|
| 05-11-2008 11:39 PM |
|
 |
Cube
Documentation Team
  
Posts: 660
Group: Docu Team
Joined: Apr 2007
Status:
Offline
Reputation: 8
|
RE: formatting style of the engine parts (perl)
But perhaps a framework would be nice.
I'm actually planning a framework using PEAR and a MVC structure.
I'm actually was talking about an AJAX framework like Prototype. We shouldn't talk about the PHP code as long as vacancy has not committed his work and we don't know how the new code looks like.
|
|
| 05-12-2008 12:37 AM |
|
 |
Zothos
Member
   
Posts: 658
Group: Dev Team
Joined: Feb 2007
Status:
Offline
Reputation: 7
|
RE: formatting style of the engine parts (perl)
jquery is the only one wich is available with the gpl licence... So lets take this one
Real programmers don't comment their code - it was hard to write, it should be hard to understand
OS : Gentoo 32bit Stage1
ispCP Version : RC4
Mods : Dovecot | Pure-ftpd
No Support via PM - Payed Support via request
|
|
| 05-12-2008 01:32 AM |
|
 |
Tseng
Junior Member

Posts: 20
Group: Registered
Joined: Apr 2008
Status:
Offline
Reputation: 0
|
RE: formatting style of the engine parts (perl)
I'm actually was talking about an AJAX framework like Prototype. We shouldn't talk about the PHP code as long as vacancy has not committed his work and we don't know how the new code looks like.
I thought he was "only" beautifying the code. I was talking about a complete new GUI. Using a MVC architecture and PEAR for the core. And I don't want to interfere with vacancy, just create a complete OO solution written in PHP5.
|
|
| 05-12-2008 01:39 AM |
|
 |
Cube
Documentation Team
  
Posts: 660
Group: Docu Team
Joined: Apr 2007
Status:
Offline
Reputation: 8
|
RE: formatting style of the engine parts (perl)
I'm not sure what he is doing, for sure he is beatifying it, but one of the main reasons why he does it, is that he wanted to make the code more secure. He also wanted to make a DNS management, but I'm not sure if this is part of the recode project.
Doing everything completely new (PHP and HTML) is a bit too much I think, talking about it is easy, but realising is not. I do not want to demotivate, but there were already many who had big plans, but there were no results.
|
|
| 05-12-2008 02:51 AM |
|
 |
ispcomm
Junior Member

Posts: 88
Group: Registered
Joined: Apr 2008
Status:
Offline
Reputation: 3
|
RE: formatting style of the engine parts (perl)
I do not want to demotivate, but there were already many who had big plans, but there were no results.
I've seen this in many projects already. It's the nature of open source. However a more formal code and a "Framework" would be a good start. There's no need to invent the wheel also. Light frameworks like codeigniter (or better kohana which is fully OO and gpl) would be a good start already.
Regarding me... the panel will be an integral part of my full-day work (as is vhcs now), so I'm motivated. Also, I'm starting slowly... reformatting the perl code so I can understand the engine better and be able to tweak it and fix it. I'll have a few servers currently on sarge to update in the next months and this is a very good reason to move from vhcs to ispcp.
I'm writing some ensim migration scripts as I'll have to convert a few servers currently running ensim. That is why I'm most interested in the engine instead of the front office (php).
I can post a perl guideline, and that would be very similar to the php guideline (which is in turn similar to the pear/cpan ones).
I guess there's a reason for most guidelines being similar: perhaps that is be best compromise.
I'll experiment a little while I wait for your decisions regarding this stuff.
ispcomm.
|
|
| 05-12-2008 03:09 AM |
|
 |
|
|