3 ms·

"handle setting the attributes and ensuring the form values persist between requests" To me this falls under the category of "automation of repetitive tasks" -

by dools 15y ago

"handle setting the attributes and ensuring the form values persist between requests" To me this falls under the category of "automation of repetitive tasks" - so long as I'm still fundamentally working with markup in my templates, a bit of automation never goes astray!

wvenable 15y ago
But something like this: <label>Date:</label><ctl:DateBox id="Date" /> <label>Name:</label><ctl:TextBox id="Name" /> ...is an abstraction. I think your claim that you don't like abstractions isn't right; you just prefer a specific level of abstraction. Abstraction and automating repetitive tasks tends to go together -- you are specifically hiding repetitive details so you don't have to deal with them. Now some people completely abstract away HTML with something like Haml; but I personally prefer something lower level than that.
- dools 15y ago
  "...is an abstraction" That's the type of abstraction that I'm specifically opposing here. Each node in my template should correlate to one node in the resulting markup. In other words, my "HTML template guy" should be able to construct the interface in it's entirety, with my "developer guy" adding in the functionality. The "HTML Template guy" should not need to know what type of markup he's allowed to use in order to allow the developer guy to deploy his templates with ctl:DateBox.
  - wvenable 15y ago
    > Each node in my template should correlate to one node in the resulting markup. That's pretty limited though. A <ctl:TextBox> might be one-to-one to an HTML <input type="textbox"> but it's extremely useful for not repeating yourself to have controls that are much more complicated than that. For example, my Datebox control has an automatic JavaScript popup calendar. I could write code to do that over and over and over in every template but that's a huge waste of time and effort. I'm not sure why anyone would be against that.
  - dools 15y ago
    "That's pretty limited though. A <ctl:TextBox> might be one-to-one to an HTML <input type="textbox"> but it's extremely useful for "not repeating yourself" to have controls that are much more complicated than that. For example, my Datebox control has an automatic JavaScript popup calendar. I could write code to do that over and over and over in every template but that's a huge waste of time and effort." The thing is that, with JavaScript libraries as they are these days, "the code to create a calendar popup" is basically already a library. Also, the person who's going to be creating that interface needs the freedom to be able to decide how they want to solve that problem, for that interface. Having a library of ways you've done it in the past allows you to re-use solutions. If you find that you have a common chunk of code that you use everywhere on one particular project, put it in an include - but creating "widgets" like this, in my experience, always leads to problems when working with more than one person on a project.
    - wvenable 15y ago
      > "the code to create a calendar popup" is basically already a library. Exactly. All my widgets use jQuery and whatever libraries exist for things like calendar popups. But the library is still somewhat low-level; if I want to use a date field (and my application has many date fields) I have to type a hell of a lot of nearly identical boilerplate HTML and JavaScript for each instance. With a simple abstraction, all that trouble goes away. Even better, if I want to swap out the calendar library (which has, in fact, actually happened) then I can do so in just one place. > If you find that you have a common chunk of code that you use everywhere on one particular project, put it in an include That's insufficient. Very few things can simply be dropped into an include and used effectively. Code reuse sometimes requires more than simply calling a function. > but creating "widgets" like this, in my experience, always leads to problems when working with more than one person on a project. I find the opposite; the widget is a self contained reusable item -- it could not be easier for other people to use in a project. It automatically promotes consistency. Desktop applications are built this way and there's nothing worse than a project that doesn't use the standard widgets.
      - kiiski 15y ago
        > "if I want to use a date field (and my application has many date fields) I have to type a hell of a lot of nearly identical boilerplate HTML and JavaScript for each instance. " You know that you could just do something like "$('.datefield').makeThisADateField()"? Although I do agree with your point.

by dools 15y ago

wvenable 15y ago

But something like this: <label>Date:</label><ctl:DateBox id="Date" /> <label>Name:</label><ctl:TextBox id="Name" /> ...is an abstraction. I think your claim that you don't like abstractions isn't right; you just prefer a specific level of abstraction. Abstraction and automating repetitive tasks tends to go together -- you are specifically hiding repetitive details so you don't have to deal with them. Now some people completely abstract away HTML with something like Haml; but I personally prefer something lower level than that.

dools 15y ago
"...is an abstraction" That's the type of abstraction that I'm specifically opposing here. Each node in my template should correlate to one node in the resulting markup. In other words, my "HTML template guy" should be able to construct the interface in it's entirety, with my "developer guy" adding in the functionality. The "HTML Template guy" should not need to know what type of markup he's allowed to use in order to allow the developer guy to deploy his templates with ctl:DateBox.
- wvenable 15y ago
  > Each node in my template should correlate to one node in the resulting markup. That's pretty limited though. A <ctl:TextBox> might be one-to-one to an HTML <input type="textbox"> but it's extremely useful for not repeating yourself to have controls that are much more complicated than that. For example, my Datebox control has an automatic JavaScript popup calendar. I could write code to do that over and over and over in every template but that's a huge waste of time and effort. I'm not sure why anyone would be against that.
- dools 15y ago
  "That's pretty limited though. A <ctl:TextBox> might be one-to-one to an HTML <input type="textbox"> but it's extremely useful for "not repeating yourself" to have controls that are much more complicated than that. For example, my Datebox control has an automatic JavaScript popup calendar. I could write code to do that over and over and over in every template but that's a huge waste of time and effort." The thing is that, with JavaScript libraries as they are these days, "the code to create a calendar popup" is basically already a library. Also, the person who's going to be creating that interface needs the freedom to be able to decide how they want to solve that problem, for that interface. Having a library of ways you've done it in the past allows you to re-use solutions. If you find that you have a common chunk of code that you use everywhere on one particular project, put it in an include - but creating "widgets" like this, in my experience, always leads to problems when working with more than one person on a project.
  - wvenable 15y ago
    > "the code to create a calendar popup" is basically already a library. Exactly. All my widgets use jQuery and whatever libraries exist for things like calendar popups. But the library is still somewhat low-level; if I want to use a date field (and my application has many date fields) I have to type a hell of a lot of nearly identical boilerplate HTML and JavaScript for each instance. With a simple abstraction, all that trouble goes away. Even better, if I want to swap out the calendar library (which has, in fact, actually happened) then I can do so in just one place. > If you find that you have a common chunk of code that you use everywhere on one particular project, put it in an include That's insufficient. Very few things can simply be dropped into an include and used effectively. Code reuse sometimes requires more than simply calling a function. > but creating "widgets" like this, in my experience, always leads to problems when working with more than one person on a project. I find the opposite; the widget is a self contained reusable item -- it could not be easier for other people to use in a project. It automatically promotes consistency. Desktop applications are built this way and there's nothing worse than a project that doesn't use the standard widgets.
    - kiiski 15y ago
      > "if I want to use a date field (and my application has many date fields) I have to type a hell of a lot of nearly identical boilerplate HTML and JavaScript for each instance. " You know that you could just do something like "$('.datefield').makeThisADateField()"? Although I do agree with your point.