3 ms·

"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 h

by 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

> "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.