Prev: get opacity value
Next: Using Javascript to look at a frame's contents from another (sibling) frame
From: optimistx on 21 Nov 2009 06:32
It is fun to add a piece of short code to a project, eg. a method of
a nice object/constructor without worrying, which other possibly
numerous locations in the same project have to be changed.

But as the code grows, everything starts to depend on everything
else, the code feels like spaghetti, entangled, and the fun ends.
Which practical principles would keep the fun as long as possible?

How to arrange code so that more or less unknown future changes
would occur in as few separate locations as possible and reasonable?

with still other words:

How to organize js, html, css to achieve good encapsulation and
modularity of all written code?



Books about programming recommend writing classes/objects, which
have clear interfaces, follow certain design patterns and rules:
Separate interface and implementation.
Use encapsulation.
Define classes carefully, avoid monster classes.
Put one task to a method, not many.
Put css to a separate file.
Put js to separet file(s).

Etc, those generally make sense and feel good.

So I do that and the problem is solved, uh?

Between css and html there seems to be no serious problems:
selectors and tags are their common ground, nothing else
to worry about.

css and js seem to live in different worlds in my programs (so far),
no entanglement, no problems.

Between js and html there is a chicken and egg problem. Who is
the boss?

If I write a nice js-'class'/object e.g. to update some program
settings given by the user, the program soon ends up in manipulating
complex forms 'far away on an html-page', breaking encapsulation.
There are at least two code locations to worry about: html-form and
js-methods of the object ( with events).

The obvious idea to generate html-code inside js-object sounded
fascinating at first, but in tests the code started to feel
artificial, long and clumsy especially, if avoiding usage of
innerHTML. The generated html-code would be appended to the
existing htmlelement(s) using the class or id.(compare css).

Is this way of 'having js-constructor as a boss', and generating
html-code with commands document.createElement, element.appendChild
etc the way to go, anyhow? What have you used?

If the input form is written in html and js-code is added to its
elements, the code feels oldfashioned <a href="#" onclick=
"do wonderful things here>...</a> type
of code, but it has the advantage of being in one place only.

There is the other extreme: put everything into js, leave only
minimal html, generate html dynamically with js.

The balance between the extremes has to be found, but how?
Example pages?


---

The usage of indeterminate and fuzzy words is intentional here.

From: wilq on 23 Nov 2009 04:16
On Nov 21, 12:32 pm, "optimistx" <optimi...(a)hotmail.com> wrote:
> It is fun to add  a piece of short code to a project, eg. a method of
> a nice object/constructor without worrying, which other possibly
> numerous locations in the same project have to be changed.
>
> But as the code grows, everything starts to depend on everything
> else, the code feels like spaghetti, entangled,  and the fun ends.
> Which practical principles would keep the fun as long as possible?
>
> How to arrange code so that more or less unknown future changes
> would occur in as few separate locations as possible and reasonable?
>
> with still other words:
>
> How to organize js, html, css  to achieve good encapsulation and
> modularity of all written code?
>
> Books about programming recommend writing classes/objects, which
> have clear interfaces, follow certain design patterns and rules:
> Separate interface and implementation.
> Use encapsulation.
> Define classes carefully, avoid monster classes.
> Put one task to a method, not many.
> Put css to a separate file.
> Put js to separet file(s).
>
> Etc, those generally make sense and feel good.
>
> So I do that and the problem is solved, uh?
>
> Between css and html there seems to be no serious problems:
> selectors and tags are their common ground, nothing else
> to worry about.
>
> css and js seem to live in different worlds in my programs (so far),
> no entanglement, no problems.
>
> Between js and html there is a chicken and egg problem. Who is
> the boss?
>
> If I write a nice js-'class'/object e.g. to update some program
> settings given by the user, the program soon ends up in manipulating
> complex forms 'far away on an html-page', breaking encapsulation.
> There are at least two code locations to worry about: html-form and
> js-methods of the object ( with events).
>
> The obvious idea to generate html-code inside js-object sounded
> fascinating at first, but in tests the code started to feel
> artificial, long and clumsy especially, if avoiding usage of
> innerHTML. The generated html-code would be appended to the
> existing htmlelement(s) using the class or id.(compare css).
>
> Is this way of 'having js-constructor as a boss', and generating
> html-code with commands document.createElement, element.appendChild
> etc the way to go, anyhow? What have you used?
>
> If the input form is written in html and js-code is added to its
> elements, the code feels oldfashioned <a href="#" onclick=
> "do wonderful things here>...</a>  type
> of code, but it has the advantage of being in one place only.
>
> There is the other extreme: put everything into js, leave only
> minimal html, generate html dynamically with js.
>
> The balance between the extremes has to be found, but how?
> Example pages?
>
> ---
>
> The usage of indeterminate and fuzzy words is intentional here.

1. Its more complicated that you would think at first... In bigger
project its good to have a nice build system (there are at least few
solutions for that right now, and its easy to create own one). It
could take care of things like building needed HTML/CSS/JS from many
separated files that you create to manage fragmentation.

2. IMHO, and after doing some test on different environment I have to
say that from performance side its adviceable to put everything in
simple HTML. I never tried that, but you could even put some
"template" elements in HTML with "display:none" in CSS, and then clone
them if needed from JS side. Basically I think that its a good idea to
separate those layers, but... It all depends on cases. Sometimes you
just cant do it differently :(

3. I would rather not use inline Javascript as it makes more difficult
to maintain in future. This might be only personal feeling, but try to
do some bigger project this way then - I think - you will
understand ;)
From: David Mark on 23 Nov 2009 04:41
On Nov 23, 4:16 am, wilq <wil...(a)gmail.com> wrote:
> On Nov 21, 12:32 pm, "optimistx" <optimi...(a)hotmail.com> wrote:
>
>
>
> > It is fun to add  a piece of short code to a project, eg. a method of
> > a nice object/constructor without worrying, which other possibly
> > numerous locations in the same project have to be changed.
>
> > But as the code grows, everything starts to depend on everything
> > else, the code feels like spaghetti, entangled,  and the fun ends.
> > Which practical principles would keep the fun as long as possible?
>
> > How to arrange code so that more or less unknown future changes
> > would occur in as few separate locations as possible and reasonable?
>
> > with still other words:
>
> > How to organize js, html, css  to achieve good encapsulation and
> > modularity of all written code?
>
> > Books about programming recommend writing classes/objects, which
> > have clear interfaces, follow certain design patterns and rules:
> > Separate interface and implementation.
> > Use encapsulation.
> > Define classes carefully, avoid monster classes.
> > Put one task to a method, not many.
> > Put css to a separate file.
> > Put js to separet file(s).
>
> > Etc, those generally make sense and feel good.
>
> > So I do that and the problem is solved, uh?
>
> > Between css and html there seems to be no serious problems:
> > selectors and tags are their common ground, nothing else
> > to worry about.
>
> > css and js seem to live in different worlds in my programs (so far),
> > no entanglement, no problems.
>
> > Between js and html there is a chicken and egg problem. Who is
> > the boss?
>
> > If I write a nice js-'class'/object e.g. to update some program
> > settings given by the user, the program soon ends up in manipulating
> > complex forms 'far away on an html-page', breaking encapsulation.
> > There are at least two code locations to worry about: html-form and
> > js-methods of the object ( with events).
>
> > The obvious idea to generate html-code inside js-object sounded
> > fascinating at first, but in tests the code started to feel
> > artificial, long and clumsy especially, if avoiding usage of
> > innerHTML. The generated html-code would be appended to the
> > existing htmlelement(s) using the class or id.(compare css).
>
> > Is this way of 'having js-constructor as a boss', and generating
> > html-code with commands document.createElement, element.appendChild
> > etc the way to go, anyhow? What have you used?
>
> > If the input form is written in html and js-code is added to its
> > elements, the code feels oldfashioned <a href="#" onclick=
> > "do wonderful things here>...</a>  type
> > of code, but it has the advantage of being in one place only.
>
> > There is the other extreme: put everything into js, leave only
> > minimal html, generate html dynamically with js.
>
> > The balance between the extremes has to be found, but how?
> > Example pages?
>
> > ---
>
> > The usage of indeterminate and fuzzy words is intentional here.
>
> 1. Its more complicated that you would think at first... In bigger
> project its good to have a nice build system (there are at least few
> solutions for that right now, and its easy to create own one). It
> could take care of things like building needed HTML/CSS/JS from many
> separated files that you create to manage fragmentation.

Yes. Offline automated processes eliminate redundant editing without
affecting the end-user.

>
> 2. IMHO, and after doing some test on different environment I have to
> say that from performance side its adviceable to put everything in
> simple HTML. I never tried that, but you could even put some
> "template" elements in HTML with "display:none" in CSS, and then clone
> them if needed from JS side.

No. You can't hide "templates" in your markup. Some users will end
up seeing (or hearing) them.

> Basically I think that its a good idea to
> separate those layers, but... It all depends on cases. Sometimes you
> just cant do it differently :(

There is virtually always some coupling (e.g. ID's and classes in the
markup are referenced in the CSS and sometimes by scripts).

>
> 3. I would rather not use inline Javascript as it makes more difficult
> to maintain in future.

See #1. ;)

> This might be only personal feeling, but try to
> do some bigger project this way then - I think - you will
> understand ;)

There are exceptions to this rule. For instance, if you want client
side validation to work during the load, you use the onsubmit
attribute. Otherwise you would either have to hide the form during
loading and show it on load (else the user sees two different
behaviors, one during the load and one after).

That's what has led to all of the "unobtrusive" nuttiness (e.g.
endlessly trying and failing to spot a viable DOMContentReady pattern
to get around self-imposed performance penalties and other avoidable
issues). Easy enough to avoid all of that without penalizing your
users (or yourself) if you understand point #1.
From: optimistx on 26 Nov 2009 06:06
wilq wrote:
>
> 1. Its more complicated that you would think at first... In bigger
> project its good to have a nice build system (there are at least few
> solutions for that right now, and its easy to create own one). It
> could take care of things like building needed HTML/CSS/JS from many
> separated files that you create to manage fragmentation.
>
> 2. IMHO, and after doing some test on different environment I have to
> say that from performance side its adviceable to put everything in
> simple HTML. I never tried that, but you could even put some
> "template" elements in HTML with "display:none" in CSS, and then clone
> them if needed from JS side. Basically I think that its a good idea to
> separate those layers, but... It all depends on cases. Sometimes you
> just cant do it differently :(
>
> 3. I would rather not use inline Javascript as it makes more difficult
> to maintain in future. This might be only personal feeling, but try to
> do some bigger project this way then - I think - you will
> understand ;)

Thanks for your opinions. I see that at least you understood my
complicated question correctly :)

Could you or any other reader give an example of a build
system of item 1 above? (I tried with google, but got too
indefinite hits).

Item 2 of your list: yes, that trick is nice, I have used that also,
but now I am experimenting to generate the html dynamically
with js. My programs are mostly under 100 kbytes each, and
currently no need to work in teams.

---------

As an example we could imagine a task to view/update some
javascript program settings. In principle the program contains
a sets of values in various objects and the user wants to
update one or several of them:

1. display a form to update parameter(s)
2. show parameter name(s) and value(s) on a form.
3. if the user changes a value, check it, and if it is
ok, the accept it as a new value of the parameter, else
give an error message
4. hide the form

It is almost ridiculous how a simple task becomes so complicated
that the best brains of all humankind think of this days in an out,
getting ziljons of different ways to accomplish this.

I tried to write a general little js-program with appropriate
principles proclaimed here and elsewhere: inheritance,
encapsulation, oop , reuse, short and compact, easy to read
(and write).
Hundreds of lines of code, soon thousands. Ugly.
Too complicated. `Lots of things to improve or redesign.

a(i) = 'something'
....update...
a(i) = 'something else' ;

How to accomplish this simply, nicely, ...?

(uh, it helped to complain ...)




From: Richard Cornford on 26 Nov 2009 07:39
On Nov 26, 11:06 am, optimistx wrote:
<snip>
> It is almost ridiculous how a simple task becomes so
> complicated that the best brains of all humankind think
> of this days in an out, getting ziljons of different
> ways to accomplish this.

If the intention is that readers derive sense from that sequence of
words then it is unlikely to be achieved.

> I tried to write a general little js-program with appropriate
> principles proclaimed

Proclaimed?

> here and elsewhere: inheritance,
> encapsulation, oop , reuse, short and compact,

"short and compact"?

> easy to read (and write).

"easy to write"?

> Hundreds of lines of code, soon thousands. Ugly.
> Too complicated. `Lots of things to improve or redesign.
>
> a(i) = 'something'
> ...update...
> a(i) = 'something else' ;

Assigning to the result of a function call is not something that you
should expect to get away with in javascript (the language's syntax
allows it, but only host methods are allowed to return something that
can be assigned to).

> How to accomplish this simply, nicely, ...?
>
> (uh, it helped to complain ...)

Psychologically, perhaps. From this, and a previous question you
asked, it seems that you are experiencing problems following from the
accumulating complexity in the code you are writing. Which isn't
surprising as increasing complexity does introduce problems with
managing that complexity, and that is why there are (at lest some of)
those "principles" you mentioned.

The thing is that you can talk about as many "principles" as you like
but if you are not perceiving them as assisting in managing the
complexity you are building all that talk is hollow. Either you don't
understand them fully, are not applying them correctly/appropriately,
or are trying to apply the wrong principles or apply them in the wrong
places or in the wrong way. Any of these are unlikely to be addressed
by more abstract talk of "principles", 'best practices', etc. At some
point it will come down to the code you are writing, and getting
someone with practical experience of complex systems written in
javascript to look at it and say what you are doing wrong (obviously
in their opinion, but that is why you need someone with the experience
to do it). Granted you may not enjoy the experience, but you are
likely to benefit form it.

Richard.
 |  Next  |  Last
Pages: 1 2
Prev: get opacity value
Next: Using Javascript to look at a frame's contents from another (sibling) frame