Re: Abstracting HTML/CSS
The problem your trying to solve - inconsistencies in supplied markup - is
best by making the markup consistent in the first place. As a user of
templates myself, I allocate up to 2 hours to modify any supplied HTML to
match my systems standard. If I hire a sub-contractor to produce the HTML, I
tell them the standard before the work commences too.
I understand what your trying to achieve with the use of helpers, but my
opinion is that is not an appropriate solution to your original problem.
Hope this helps,
Richard
On Mon, Jul 13, 2009 at 6:12 AM, Sake e.delba...@gmail.com wrote:
Yes, but I'm talking about the case where you're using someone else's
code, be it a sub-contractor who's chopped up the image into html or a
pre-made template. This seems to me a nice solution, no?
On Jul 12, 11:28 pm, Dr. Loboto drlob...@gmail.com wrote:
By my option much better write CSS based on cake default elements and
classes for forms (cake markup there is extremely styleable). And
changing your buttons from $html-submit to an image-based box link
is initially bad idea as it breaks default form behavior.
On Jul 13, 9:04 am, Sake e.delba...@gmail.com wrote:
I write code in cakephp (although this question can apply to anything
that uses HTML/CSS) and find the default skin very uninspiring. In a
fit of depression I bought this : [http://themeforest.net/item/simpla-
admin-flexible-user-friendly-admin-skin/46073] and tried to install it
into the application I was working on.
I quickly realized that the CSS/markup combo that cakePHP uses is not
the same that the simpla writers had in mind, and had to go back and
change all the markup on my forms, etc etc.
My question is this; Is it a bad idea to abstract my HTML into common
elements? I was thinking of doing something like this:
?php
class InterfaceHelper extends AppHelper
{
var $name = 'Interface';
var $Theme = null;
function beforeLayout()
{
parent::beforeLayout();
}
function __loadTheme()
{
$theme = $this-getTheme();
App::import('Vendor','interface_themes/default');
App::import('Vendor','interface_themes/'.$theme);
$className =
Inflector::camelize($this-getTheme()).Theme;
$d = new $className();
$this-Theme = $d;
}
function getTheme()
{
if(!Configure::read('edlib.theme'))
{
return default;
}
else
{
return Configure::read('edlib.theme');
}
}
public function __call( $method, $args )
{
$this-__loadTheme();
return $this-Theme-$method($args);
}
}
?
Now, all html elements for my theme would be defined in functions
called ::open_table(), ::open_row(), ::open_cell() (for example) and
would return table,tr and td respectively (for example) as
follows :
?php
class DefaultTheme
{
var $name = 'Default';
function open_box($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
//print pr($title);die();
$text = 'div class=box' .
'h2'.$title.'/h2'.
'div class=block';
return $text;
}
function close_box()
{
return '/div'.\n\t\t.'/div';
}
function page_heading($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
return 'h2 id=page-heading'.$title.'/h2';
}
// etc...
}
?
This has the following advantage; Need a different markup for forms?
Just over-ride your DefaultTheme::open_form() function in a NewTheme
class. Each theme has a demo file that allows you to both display and
test all interace elements defined by DefaultTheme class. Let's say
you're changing your buttons from $html-submit to an image-based box
link, you could over-ride $interface-button() instead of changing
every line of code that uses the button.
My question
Re: Abstracting HTML/CSS
On Mon, Jul 13, 2009 at 1:12 AM, Sakee.delba...@gmail.com wrote: Yes, but I'm talking about the case where you're using someone else's code, be it a sub-contractor who's chopped up the image into html or a pre-made template. This seems to me a nice solution, no? Isn't this what CakePHP themes are for? Build out your CakePHP based on the header/footer/wrapper markup in your purchased theme. The Form Helper can accept arguments for classes, ids, before tag, after tag, etc. so between that and your themed views, I don't see what else cannot be achieved through CSS. It's a bit of work, obviously, but integrating any 3rd-party HTML/CSS template in any framework/forum/CMS/etc. is going to take some work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
Re: Abstracting HTML/CSS
On Mon, Jul 13, 2009 at 11:34 AM, GravyFacegravyf...@gmail.com wrote: On Mon, Jul 13, 2009 at 1:12 AM, Sakee.delba...@gmail.com wrote: Yes, but I'm talking about the case where you're using someone else's code, be it a sub-contractor who's chopped up the image into html or a pre-made template. This seems to me a nice solution, no? Isn't this what CakePHP themes are for? Build out your CakePHP based on the header/footer/wrapper markup in your purchased theme. Oops. Should say CakePHP based layout. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups CakePHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
Re: Abstracting HTML/CSS
The thing is that my solution eliminates this work and offers you and
your developpers more freedom.
Above and beyond the obvious advantages of super rapid prototyping, I
imagine my code eventually becoming a repository of interface elements
that can be used without having to know html/css, empowering the
backend developper who doesn't want to spend time learning the
intricacies of HTML/CSS and making his applications, as a whole, look
alot better.
What I see is this :
Every theme will have a demo page which consists of tabbed content
such as, Buttons, Forms, Tables, Article previews, Code Blocks,
etc Clicking on buttons for example will give a window with all
button styles included in this Theme. For each button, an
explanation of the code required to use it will be provided, and it
will look something like:
$interface-button($style = 'Checkmark',$label = 'Ok');
etc etc...
I know that you can solve this by enforcing YOUR way of writing
markup, but isn't an abstraction such as my interface helper a better,
more flexible solution?
I see why somebody who knows HTML/CSS inside out would find it
unnecessary, but what about those who would rather focus on the
million other parts of their web app they want to build without having
to go through HTML/CSS headaches?
I know my Version1 will be alot nicer if I can pull from a library of
interface widgets. What do you think?
On Jul 13, 10:57 am, Richard rclay...@gmail.com wrote:
The problem your trying to solve - inconsistencies in supplied markup - is
best by making the markup consistent in the first place. As a user of
templates myself, I allocate up to 2 hours to modify any supplied HTML to
match my systems standard. If I hire a sub-contractor to produce the HTML, I
tell them the standard before the work commences too.
I understand what your trying to achieve with the use of helpers, but my
opinion is that is not an appropriate solution to your original problem.
Hope this helps,
Richard
On Mon, Jul 13, 2009 at 6:12 AM, Sake e.delba...@gmail.com wrote:
Yes, but I'm talking about the case where you're using someone else's
code, be it a sub-contractor who's chopped up the image into html or a
pre-made template. This seems to me a nice solution, no?
On Jul 12, 11:28 pm, Dr. Loboto drlob...@gmail.com wrote:
By my option much better write CSS based on cake default elements and
classes for forms (cake markup there is extremely styleable). And
changing your buttons from $html-submit to an image-based box link
is initially bad idea as it breaks default form behavior.
On Jul 13, 9:04 am, Sake e.delba...@gmail.com wrote:
I write code in cakephp (although this question can apply to anything
that uses HTML/CSS) and find the default skin very uninspiring. In a
fit of depression I bought this : [http://themeforest.net/item/simpla-
admin-flexible-user-friendly-admin-skin/46073] and tried to install it
into the application I was working on.
I quickly realized that the CSS/markup combo that cakePHP uses is not
the same that the simpla writers had in mind, and had to go back and
change all the markup on my forms, etc etc.
My question is this; Is it a bad idea to abstract my HTML into common
elements? I was thinking of doing something like this:
?php
class InterfaceHelper extends AppHelper
{
var $name = 'Interface';
var $Theme = null;
function beforeLayout()
{
parent::beforeLayout();
}
function __loadTheme()
{
$theme = $this-getTheme();
App::import('Vendor','interface_themes/default');
App::import('Vendor','interface_themes/'.$theme);
$className =
Inflector::camelize($this-getTheme()).Theme;
$d = new $className();
$this-Theme = $d;
}
function getTheme()
{
if(!Configure::read('edlib.theme'))
{
return default;
}
else
{
return Configure::read('edlib.theme');
}
}
public function __call( $method, $args )
{
$this-__loadTheme();
return $this-Theme-$method($args);
}
}
?
Now, all html elements for my theme would be defined in functions
called ::open_table(), ::open_row(), ::open_cell() (for example) and
would return table,tr and td respectively (for example) as
follows :
?php
class
Re: Abstracting HTML/CSS
By my option much better write CSS based on cake default elements and
classes for forms (cake markup there is extremely styleable). And
changing your buttons from $html-submit to an image-based box link
is initially bad idea as it breaks default form behavior.
On Jul 13, 9:04 am, Sake e.delba...@gmail.com wrote:
I write code in cakephp (although this question can apply to anything
that uses HTML/CSS) and find the default skin very uninspiring. In a
fit of depression I bought this : [http://themeforest.net/item/simpla-
admin-flexible-user-friendly-admin-skin/46073] and tried to install it
into the application I was working on.
I quickly realized that the CSS/markup combo that cakePHP uses is not
the same that the simpla writers had in mind, and had to go back and
change all the markup on my forms, etc etc.
My question is this; Is it a bad idea to abstract my HTML into common
elements? I was thinking of doing something like this:
?php
class InterfaceHelper extends AppHelper
{
var $name = 'Interface';
var $Theme = null;
function beforeLayout()
{
parent::beforeLayout();
}
function __loadTheme()
{
$theme = $this-getTheme();
App::import('Vendor','interface_themes/default');
App::import('Vendor','interface_themes/'.$theme);
$className =
Inflector::camelize($this-getTheme()).Theme;
$d = new $className();
$this-Theme = $d;
}
function getTheme()
{
if(!Configure::read('edlib.theme'))
{
return default;
}
else
{
return Configure::read('edlib.theme');
}
}
public function __call( $method, $args )
{
$this-__loadTheme();
return $this-Theme-$method($args);
}
}
?
Now, all html elements for my theme would be defined in functions
called ::open_table(), ::open_row(), ::open_cell() (for example) and
would return table,tr and td respectively (for example) as
follows :
?php
class DefaultTheme
{
var $name = 'Default';
function open_box($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
//print pr($title);die();
$text = 'div class=box' .
'h2'.$title.'/h2'.
'div class=block';
return $text;
}
function close_box()
{
return '/div'.\n\t\t.'/div';
}
function page_heading($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
return 'h2 id=page-heading'.$title.'/h2';
}
// etc...
}
?
This has the following advantage; Need a different markup for forms?
Just over-ride your DefaultTheme::open_form() function in a NewTheme
class. Each theme has a demo file that allows you to both display and
test all interace elements defined by DefaultTheme class. Let's say
you're changing your buttons from $html-submit to an image-based box
link, you could over-ride $interface-button() instead of changing
every line of code that uses the button.
My question is, am I going a little crazy here? I feel like this will
help my quick iteration process become even quicker. I can break all
of my apps down into interface elements such as forms, tables,
notification boxes, blockquotes, etc.. and then just output them
quickly using my default theme, then over-ride them once my mockup has
been approved and automatically have a working webapp that's nicely
styled in much shorter time.
What do you guys think? My other alternative approach was to compile
interface elements using my own syntax much like [http://lesscss.org/]
[2] compiles CSS. Is there a better approach?
For those who are interested, I've included a quick mockup of the code
on github for the sake of example :
http://github.com/edelbalso/cakephp_themes/tree/master
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe
Abstracting HTML/CSS
I write code in cakephp (although this question can apply to anything
that uses HTML/CSS) and find the default skin very uninspiring. In a
fit of depression I bought this : [http://themeforest.net/item/simpla-
admin-flexible-user-friendly-admin-skin/46073] and tried to install it
into the application I was working on.
I quickly realized that the CSS/markup combo that cakePHP uses is not
the same that the simpla writers had in mind, and had to go back and
change all the markup on my forms, etc etc.
My question is this; Is it a bad idea to abstract my HTML into common
elements? I was thinking of doing something like this:
?php
class InterfaceHelper extends AppHelper
{
var $name = 'Interface';
var $Theme = null;
function beforeLayout()
{
parent::beforeLayout();
}
function __loadTheme()
{
$theme = $this-getTheme();
App::import('Vendor','interface_themes/default');
App::import('Vendor','interface_themes/'.$theme);
$className =
Inflector::camelize($this-getTheme()).Theme;
$d = new $className();
$this-Theme = $d;
}
function getTheme()
{
if(!Configure::read('edlib.theme'))
{
return default;
}
else
{
return Configure::read('edlib.theme');
}
}
public function __call( $method, $args )
{
$this-__loadTheme();
return $this-Theme-$method($args);
}
}
?
Now, all html elements for my theme would be defined in functions
called ::open_table(), ::open_row(), ::open_cell() (for example) and
would return table,tr and td respectively (for example) as
follows :
?php
class DefaultTheme
{
var $name = 'Default';
function open_box($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
//print pr($title);die();
$text = 'div class=box' .
'h2'.$title.'/h2'.
'div class=block';
return $text;
}
function close_box()
{
return '/div'.\n\t\t.'/div';
}
function page_heading($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
return 'h2 id=page-heading'.$title.'/h2';
}
// etc...
}
?
This has the following advantage; Need a different markup for forms?
Just over-ride your DefaultTheme::open_form() function in a NewTheme
class. Each theme has a demo file that allows you to both display and
test all interace elements defined by DefaultTheme class. Let's say
you're changing your buttons from $html-submit to an image-based box
link, you could over-ride $interface-button() instead of changing
every line of code that uses the button.
My question is, am I going a little crazy here? I feel like this will
help my quick iteration process become even quicker. I can break all
of my apps down into interface elements such as forms, tables,
notification boxes, blockquotes, etc.. and then just output them
quickly using my default theme, then over-ride them once my mockup has
been approved and automatically have a working webapp that's nicely
styled in much shorter time.
What do you guys think? My other alternative approach was to compile
interface elements using my own syntax much like [http://lesscss.org/]
[2] compiles CSS. Is there a better approach?
For those who are interested, I've included a quick mockup of the code
on github for the sake of example :
http://github.com/edelbalso/cakephp_themes/tree/master
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
CakePHP group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---
Re: Abstracting HTML/CSS
Yes, but I'm talking about the case where you're using someone else's
code, be it a sub-contractor who's chopped up the image into html or a
pre-made template. This seems to me a nice solution, no?
On Jul 12, 11:28 pm, Dr. Loboto drlob...@gmail.com wrote:
By my option much better write CSS based on cake default elements and
classes for forms (cake markup there is extremely styleable). And
changing your buttons from $html-submit to an image-based box link
is initially bad idea as it breaks default form behavior.
On Jul 13, 9:04 am, Sake e.delba...@gmail.com wrote:
I write code in cakephp (although this question can apply to anything
that uses HTML/CSS) and find the default skin very uninspiring. In a
fit of depression I bought this : [http://themeforest.net/item/simpla-
admin-flexible-user-friendly-admin-skin/46073] and tried to install it
into the application I was working on.
I quickly realized that the CSS/markup combo that cakePHP uses is not
the same that the simpla writers had in mind, and had to go back and
change all the markup on my forms, etc etc.
My question is this; Is it a bad idea to abstract my HTML into common
elements? I was thinking of doing something like this:
?php
class InterfaceHelper extends AppHelper
{
var $name = 'Interface';
var $Theme = null;
function beforeLayout()
{
parent::beforeLayout();
}
function __loadTheme()
{
$theme = $this-getTheme();
App::import('Vendor','interface_themes/default');
App::import('Vendor','interface_themes/'.$theme);
$className =
Inflector::camelize($this-getTheme()).Theme;
$d = new $className();
$this-Theme = $d;
}
function getTheme()
{
if(!Configure::read('edlib.theme'))
{
return default;
}
else
{
return Configure::read('edlib.theme');
}
}
public function __call( $method, $args )
{
$this-__loadTheme();
return $this-Theme-$method($args);
}
}
?
Now, all html elements for my theme would be defined in functions
called ::open_table(), ::open_row(), ::open_cell() (for example) and
would return table,tr and td respectively (for example) as
follows :
?php
class DefaultTheme
{
var $name = 'Default';
function open_box($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
//print pr($title);die();
$text = 'div class=box' .
'h2'.$title.'/h2'.
'div class=block';
return $text;
}
function close_box()
{
return '/div'.\n\t\t.'/div';
}
function page_heading($args)
{
if(!$args) { $title = 'NONE'; }
else { $title = $args[0]; }
return 'h2 id=page-heading'.$title.'/h2';
}
// etc...
}
?
This has the following advantage; Need a different markup for forms?
Just over-ride your DefaultTheme::open_form() function in a NewTheme
class. Each theme has a demo file that allows you to both display and
test all interace elements defined by DefaultTheme class. Let's say
you're changing your buttons from $html-submit to an image-based box
link, you could over-ride $interface-button() instead of changing
every line of code that uses the button.
My question is, am I going a little crazy here? I feel like this will
help my quick iteration process become even quicker. I can break all
of my apps down into interface elements such as forms, tables,
notification boxes, blockquotes, etc.. and then just output them
quickly using my default theme, then over-ride them once my mockup has
been approved and automatically have a working webapp that's nicely
styled in much shorter time.
What do you guys think? My other alternative approach was to compile
interface elements using my own syntax much like [http://lesscss.org/]
[2] compiles CSS. Is there a better approach?
For those who are interested,
