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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
