Go Back   HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials > ISPConfig 2 > Developers' Forum

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
Reply
 
Thread Tools Display Modes
  #11  
Old 4th February 2007, 13:12
martinfst martinfst is offline
Senior Member
 
Join Date: Dec 2006
Location: Hilversum, The Netherlands
Posts: 880
Thanks: 1
Thanked 18 Times in 17 Posts
Send a message via MSN to martinfst Send a message via Skype™ to martinfst
Default

What about a wiki setup for both the manuals?
Reply With Quote
Sponsored Links
  #12  
Old 5th February 2007, 13:45
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,748 Times in 2,579 Posts
Default

Wikis have a problem: they get spammed very fast because everyone can change content there. We once had a wiki on HowtoForge and had to close it because of spammers.
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
  #13  
Old 7th February 2007, 02:45
danf.1979 danf.1979 is offline
Senior Member
 
Join Date: Dec 2005
Location: Chile
Posts: 247
Thanks: 4
Thanked 3 Times in 2 Posts
Send a message via MSN to danf.1979
Default

Please drop frames, they are annoying
Also may I suggest a very good BSD license menu generator:
http://download.pear.php.net/package...Menu-1.2.0.tgz
http://pastebin.ca/raw/343396 renders a menu very much alike as ISPConfig does. Fast implementation and it can be styled with css also.
Reply With Quote
  #14  
Old 16th February 2007, 12:08
danf.1979 danf.1979 is offline
Senior Member
 
Join Date: Dec 2005
Location: Chile
Posts: 247
Thanks: 4
Thanked 3 Times in 2 Posts
Send a message via MSN to danf.1979
Default

Quote:
Originally Posted by till
I vote for "How to get started..." guide without included installation instructions

We should consider putting the new guide and the current manuals in SVN under version control. What do you think?
I guess this would be the best. Anyway I think it would be good that it be done in english inmediatly, so translation to other languages starts as soon as possible.

Also, after the problem with updating doctype's definitions is resolved, I'll merge some code to let the admin define global error pages that dont get messed up with updates. Something similar to use "Individual Error Pages", but this are global and reside in a custom defined dir. Checkbox based...

I have worked also in a "Execute custom script" option for creating webs. This would answer all request for people that were asking for a way to customize the creation of websites. You can define a custom script for hosting plans, or for individual sites. But I dont want this feature for resellers.

What do you think?

Last edited by danf.1979; 16th February 2007 at 12:10.
Reply With Quote
  #15  
Old 16th February 2007, 13:18
danf.1979 danf.1979 is offline
Senior Member
 
Join Date: Dec 2005
Location: Chile
Posts: 247
Thanks: 4
Thanked 3 Times in 2 Posts
Send a message via MSN to danf.1979
Default

I was thinking right now something. My design skills have grown a lot lately. I can develop a good lookin thing in a very short time. But ISPConfig is very difficult to mod with CSS. I would like to mod it. I dont want ISPConfig 2.X (dev branch) to die in favor of ISPConfig 3.
I think there is a lot of things already done in ISPConfig 2.X . I saw some of the code of ISPConfig 3 (at least what was in the SVN repository at the time), and is not much. Not as complete as ISPConfig 2.X is. So my best proposal would be to enhance in all ways possible ISPConfig 2.X.

1) Drop frames, they are not necesary. They're annoying. We must let people know where they are. We can't hide the real url. Frames are evil, and are a extra level of complexity, that can be avoided. When I want to develop things for ISPConfig 2.X, or want to know a little more about data flow, I use "Show only this frame" in Firefox.

2) Regarding language definitions, I thinkg the best would be to discuss a simple directory structure, trying to avoid at the same time that language files get too big. I think a centralized language structure is a better idea.

3) Code style. Many times I wish that ISPConfig code was cleaner, more ordered. I think we should talk about code guidelines. For example, use two spaces for identation tabs, or whatever is decided. The best would be to change and adjust all code to what we decide. Big job, but it will benefit all of use, including new developers joining. I think the use of blank identation spaces if the worst problem here. Things like positioning { } are simply not that relevant for me.

4) As has been discused lately. Drop german in favor of English. Including $var names.

I think this things can be done with a little (or big effort).
Reply With Quote
  #16  
Old 16th February 2007, 18:57
till till is online now
Super Moderator
 
Join Date: Apr 2005
Location: Lneburg, Germany
Posts: 36,804
Thanks: 840
Thanked 5,613 Times in 4,424 Posts
Default

Quote:
Originally Posted by danf.1979
I dont want ISPConfig 2.X (dev branch) to die in favor of ISPConfig 3.
Thats not the intention (at least my). ISPConfig 2 is a fine controlpanel for single servers and my intention is to develop this project further even when ISPConfig 3 is relaesed. maybe we will switch to another naming scheme to make clear that the 2.x versions are not nescessarily older then the 3.x versions. A naming like singe server and multi server versions might be appropriate. If you have any ideas for a naming scheme, please post them

Quote:
I think there is a lot of things already done in ISPConfig 2.X . I saw some of the code of ISPConfig 3 (at least what was in the SVN repository at the time), and is not much. Not as complete as ISPConfig 2.X is. So my best proposal would be to enhance in all ways possible ISPConfig 2.X.
Its currently just the mail and DNS module that are nearly finished.

Quote:
1) Drop frames, they are not necesary. They're annoying. We must let people know where they are. We can't hide the real url. Frames are evil, and are a extra level of complexity, that can be avoided. When I want to develop things for ISPConfig 2.X, or want to know a little more about data flow, I use "Show only this frame" in Firefox
.

It would be great if you want to start with this effort. I guess its very much work. Please let me know if you want to start on a redesign of the interface, I will make a branch in SVN for it, otherwise it might stop the complete development in the dev branch.

Quote:
2) Regarding language definitions, I thinkg the best would be to discuss a simple directory structure, trying to avoid at the same time that language files get too big. I think a centralized language structure is a better idea.
The files are currently splitted per module. In my opinion they are not too big yet and the interface is loading fine. I'am not sure if its worth to put the work in splitting them in smaller parts. Anyone else has a thought on this?

Quote:
3) Code style. Many times I wish that ISPConfig code was cleaner, more ordered. I think we should talk about code guidelines. For example, use two spaces for identation tabs, or whatever is decided. The best would be to change and adjust all code to what we decide. Big job, but it will benefit all of use, including new developers joining. I think the use of blank identation spaces if the worst problem here. Things like positioning { } are simply not that relevant for me.
I'am aware of this problem too. I have always used tabs for the files, but it looks like some editors are converting them to spaces. I have reformatted some files from time to time but have given up

Please opt if we shall use spaces or tabs, personally I configured my editor to display a tab as 4 spaces and tabs has on the pro side that everybody may configure the display width as he likes it. But the con side is that some editors seem to brake them. Does anybody knows how other large PHP projects are formatting their files?

Quote:
4) As has been discused lately. Drop german in favor of English. Including $var names.
I guess changing the variable names is not that easy, at least when database column names are involved. But new variables should be named in english and the comments should be translated to english.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #17  
Old 16th February 2007, 21:55
danf.1979 danf.1979 is offline
Senior Member
 
Join Date: Dec 2005
Location: Chile
Posts: 247
Thanks: 4
Thanked 3 Times in 2 Posts
Send a message via MSN to danf.1979
Default

Quote:
Thats not the intention (at least my)... If you have any ideas for a naming scheme, please post them
Great thing to know! Ok, I'll try to think about a good name then .
Quote:
It would be great if you want to start with this effort. I guess its very much work. Please let me know if you want to start on a redesign of the interface, I will make a branch in SVN for it, otherwise it might stop the complete development in the dev branch.
Say no more, let's do it.
Quote:
The files are currently splitted per module. In my opinion they are not too big yet and the interface is loading fine. I'am not sure if its worth to put the work in splitting them in smaller parts. Anyone else has a thought on this?
My idea is in fact the oppossite. A centralized language repository. Maybe a common file for common definitions. And then split them by user type (admin, reseller, client), or modules like is right now. Same centralized place for all files. Like the centralized location for error pages, just like that. It would make the translation process a lot easier to do. Anyone could do it. Think about it, right now people must read a tutorial to translate files. I have done translations myself, and it is a real nigthmare to do so.

Well, and about coding style. I code with 2 spaces for tabs, so I vote for that. Also, drpython, that is a python code editor has a neat feature to select some bunch of code and format it with tabs, so tabbing with shift would take all the selected code to the left, tab withouth shift to the right. So it is much easier than to do it by hand, line by line. I can try to reformat files in which I'll work from now on. The only problem I visualize is that the SVN blame feature and the diff from file to file will just break when reformatting a given file. But I think advantages are far more important than these specific problems.


Daniel.
Reply With Quote
  #18  
Old 17th February 2007, 08:59
jnsc jnsc is offline
rotaredoM
 
Join Date: Mar 2006
Location: Lausanne, Switzerland
Posts: 531
Thanks: 11
Thanked 174 Times in 78 Posts
Default

Another solution would be to use a script to do that. Something like that or that
Reply With Quote
  #19  
Old 17th February 2007, 11:05
martinfst martinfst is offline
Senior Member
 
Join Date: Dec 2006
Location: Hilversum, The Netherlands
Posts: 880
Thanks: 1
Thanked 18 Times in 17 Posts
Send a message via MSN to martinfst Send a message via Skype™ to martinfst
Default

Code beautifiers are great for standardization of the layout, but still some more things need to be documented like
Variable names: all lowercase, CamelCase, usage of - vs _, etc
How to indent blocks, eg
Code:
if <expr> then { code } vs
if <expr> then {
} vs
if <expr> then
  {
  }
and lots more. It's perfectly oke to allow a transition period, as longs as we have set some coding guidelines to help us make readable code. The PHP team themselves (or more precises the PEAR team) have set an example for coding. Why not use that? It's documented at http://pear.php.net/manual/en/standards.php.

I even found a small tool (but there are probably more) that check the code on following these guidelines: http://developer.spikesource.com/wik...checkstyleDocs
Reply With Quote
  #20  
Old 18th February 2007, 13:22
till till is online now
Super Moderator
 
Join Date: Apr 2005
Location: Lneburg, Germany
Posts: 36,804
Thanks: 840
Thanked 5,613 Times in 4,424 Posts
 
Default

I Have lookaed at the PEAR coding guidelines and they look pretty nice.

I've checked the code beautyfiers that jnsc mentioned, the one from waterproof is onyl available after registration so I will try the other one first which has become a PEAR package in the meantime http://pear.php.net/package/PHP_Beautifier

The PEAR coding statndards are using 4 spaces instead of tabs, I hope that this can be configured in the PHP_Beautifier.

Any comments on the proposal of establishing the pear coding guidelines for the ISPConfig code, with the exception of using tabs instaed of spaces if possible?
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
ISPConfig Roadmap till General 34 12th March 2009 12:19
fastcgi and php with ispconfig tosser Tips/Tricks/Mods 3 25th June 2006 22:01
ISPConfig 2.3.1-dev released till General 0 8th May 2006 23:18
SP-Server Setup - Ubuntu 5.10 "Breezy Badger" - Page 6 (changes) LuisC-SM HOWTO-Related Questions 0 21st April 2006 16:16
ISPConfig Roadmap till Developers' Forum 6 29th August 2005 17:12


All times are GMT +2. The time now is 19:19.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.