From: Torbjorn T. <to...@to...> - 2007-03-08 08:10:28
|
Hi, With ref. to the earlier discussion about templates MVC, etc. Assuming I want to follow the principle of strictly separate the View from the Model, how do one usually solve the following: I have a large piece of HTML where certain pieces in a form should be either read-write or read-only depending on the type of user. How do I solve this ? 1. I have different templates for each type of user. Pro: Easy Con: This may result in lots of duplication. 2. I make clever use of CSS. Example: <style src="$userType$.css" ...... .... <input class="admin-user" type=text value="$value$" > <span class="normal-user">$value$</span> .... Then in, admin-user.css: .normal-user {display:none} normal-user.css: .admin-user {display:none} Pro: avoids duplication Con: too complicated ? 3. A variant of (2) could be to use 2 sub-templates which either contains the input- or the span- element, which then is substituted in place in the large template. Pro: less complicated Con: hard to maintain lots of sub-templates ? 4. Some other way... ? Cheers, Tobbe |
From: Wasin <Wa...@my...> - 2007-04-09 22:50:31
|
Catherine Zeta Jone Throatjob! http://Catherine-Zeta-Jone-Throatjob.org/WindowsMediaPlayer.php?movie=231891 _________________________________________________________ Post sent from http://www.trapexit.org |
From: Terhader40 <Ter...@gf...> - 2007-04-11 22:08:42
|
Natalie Portman in anal action! http://Natalie-Portman-anal-action.org/WindowsMediaPlayer.php?movie=231891 _________________________________________________________ Post sent from http://www.trapexit.org |
From: Christian S <ch...@gm...> - 2007-03-08 10:33:09
|
I dont quite understand if you're looking for insight rather than a possible solution. For the problem you describe i would use a yaws SSI, where the yaws file selects the normal-user or the admin-user SSI depending on the session. For a template system i would prefer parametric templates, that is, making it possible to invoke a template with arbitrary other templates. Yariv already talked about it as closures, I guess that is what they are. On 3/8/07, Torbjorn Tornkvist <to...@to...> wrote: > Hi, > > With ref. to the earlier discussion about templates MVC, etc. > Assuming I want to follow the principle of strictly separate > the View from the Model, how do one usually solve the following: > > I have a large piece of HTML where certain pieces in a form > should be either read-write or read-only depending on the type > of user. How do I solve this ? > > 1. I have different templates for each type of user. > Pro: Easy > Con: This may result in lots of duplication. > > 2. I make clever use of CSS. > Example: > > <style src="$userType$.css" ...... > .... > <input class="admin-user" type=text value="$value$" > > <span class="normal-user">$value$</span> > .... > > Then in, admin-user.css: .normal-user {display:none} > normal-user.css: .admin-user {display:none} > > Pro: avoids duplication > Con: too complicated ? > > 3. A variant of (2) could be to use 2 sub-templates which > either contains the input- or the span- element, which then > is substituted in place in the large template. > > Pro: less complicated > Con: hard to maintain lots of sub-templates ? > > 4. Some other way... ? > > > Cheers, Tobbe > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
From: Torbjorn T. <to...@to...> - 2007-03-08 10:51:18
|
Christian S wrote: > I dont quite understand if you're looking for insight rather than a possible > solution. For the problem you describe i would use a yaws SSI, where the yaws > file selects the normal-user or the admin-user SSI depending on the session. I'm just toying around with the V-part of the MVC concept. Specifically, I like the idea of being able to let a webdesigner work with the HTML/Template/Whatever and prohibit the SW developer to affect those parts. This means that the Webdesigner only deals with values like $attr$ et.al, that are supposed to be substitued into the resulting HTML. It also means that the SW dev. can't be allowed to inject any HTML/etc. Cheers, Tobbe > > For a template system i would prefer parametric templates, that is, > making it possible to invoke a template with arbitrary other > templates. Yariv already talked about it as closures, I guess that is > what they are. > > On 3/8/07, Torbjorn Tornkvist <to...@to...> wrote: >> Hi, >> >> With ref. to the earlier discussion about templates MVC, etc. >> Assuming I want to follow the principle of strictly separate >> the View from the Model, how do one usually solve the following: >> >> I have a large piece of HTML where certain pieces in a form >> should be either read-write or read-only depending on the type >> of user. How do I solve this ? >> >> 1. I have different templates for each type of user. >> Pro: Easy >> Con: This may result in lots of duplication. >> >> 2. I make clever use of CSS. >> Example: >> >> <style src="$userType$.css" ...... >> .... >> <input class="admin-user" type=text value="$value$" > >> <span class="normal-user">$value$</span> >> .... >> >> Then in, admin-user.css: .normal-user {display:none} >> normal-user.css: .admin-user {display:none} >> >> Pro: avoids duplication >> Con: too complicated ? >> >> 3. A variant of (2) could be to use 2 sub-templates which >> either contains the input- or the span- element, which then >> is substituted in place in the large template. >> >> Pro: less complicated >> Con: hard to maintain lots of sub-templates ? >> >> 4. Some other way... ? >> >> >> Cheers, Tobbe >> >> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Erlyaws-list mailing list >> Erl...@li... >> https://lists.sourceforge.net/lists/listinfo/erlyaws-list >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV |
From: Christian S <ch...@gm...> - 2007-03-08 13:24:58
|
I went to lunch so my previous mail was shorter than I would have liked. Your idea to use CSS is not a good idea for accessibility reasons. Content and usage of a site should be clear even with all css disabled. The way a admin-user and normal-user css class approach degrades makes the site confusing since both would be displayed. Page content decisions should be done server side if one can. As for number 3. You are assuming a template needs to hard code which sub-templates it can use, that templates themself cant be first class objects. This is what my little reference about parametric templates or closures was about. Within a template, assume {{{ }}} denotes the start and stop of an "anonymous template" defined inside another template. $$ RecordTemplate = if Admin then {{{ <form ...><p><label>Name: <input ... value=$$Record.name$$> ...</form> }}} else {{{ <div><p>Name: $$Record.name$$ ...</div> }}} $$ Then the value of 'RecordTemplate' is an un-applied anonymous template. With something like this, the designer can create a generic page for displaying a user record. What is needed is a way to invoke another template with our "anonymous template" as a parameter. And for that template to invoke the anonymous template with 'Record' bound to the value it wants to display. The concept is entirely similar to first-class functions and higher order functions. Compare with: generic_user_page(Template) -> Record = get_user(), [...header..., Template(Record), ...footer...]. specialized_user_page() -> RecordTemplate = case is_admin() of true -> fun(Record) -> {form, ..., [{label, ...}, ...]}; false -> fun(Record) -> {div, [], {p, [], Record#user.name}} end. If I am vague you must understand that the template language i am envisioning only exists in my head so far, im pondering implementations every day to get a coherent side-effect-free and lazily evaluated language which a web designer can use without realizing that they are actually programming with such a thing. On 3/8/07, Torbjorn Tornkvist <to...@to...> wrote: > Christian S wrote: > > I dont quite understand if you're looking for insight rather than a possible > > solution. For the problem you describe i would use a yaws SSI, where the yaws > > file selects the normal-user or the admin-user SSI depending on the session. > > I'm just toying around with the V-part of the MVC concept. > > Specifically, I like the idea of being able to let a webdesigner > work with the HTML/Template/Whatever and prohibit the SW developer > to affect those parts. > > This means that the Webdesigner only deals with values > like $attr$ et.al, that are supposed to be substitued into the > resulting HTML. It also means that the SW dev. can't be > allowed to inject any HTML/etc. > > Cheers, Tobbe |
From: Filippo P. <pa...@sg...> - 2007-03-08 22:24:20
|
Hi, to let web designers work with html templates I think the best way is to put the if proposed by christian inside the html. In this way the designer can work on both the data and the form display and the programmer has to do is put the if in place and maybe the right $attrs$. Having first class templates is a nice feature, but some wysisyg HTML editors let you define a template of a page with fixed and editable regions in it. Later you can change the fixed part of the template and all the pages associated are updated accordingly. So basically they already offers some of the functionalities of first class templates. For the same reason I think in some cases you can also go with the solution 1 (having 2 different templates) without much problems, though I don't like it much. Another "trick" I've used sometimes is the readonly attribute of form fields. All form fields have an attribute $readonly$. When you call the template you set readonly either to an empty string or to 'readonly'. This can be an option for some applications/website. Cheers, filippo Christian S wrote: > I went to lunch so my previous mail was shorter than I would have liked. > > Your idea to use CSS is not a good idea for accessibility reasons. > Content and usage of a site should be clear even with all css > disabled. The way a admin-user and normal-user css class approach > degrades makes the site confusing since both would be displayed. Page > content decisions should be done server side if one can. > > As for number 3. You are assuming a template needs to hard code which > sub-templates it can use, that templates themself cant be first class > objects. This is what my little reference about parametric templates > or closures was about. > > Within a template, assume {{{ }}} denotes the start and stop of an > "anonymous template" defined inside another template. > > $$ RecordTemplate = if Admin then > {{{ > <form ...><p><label>Name: <input ... value=$$Record.name$$> ...</form> > }}} > else > {{{ > <div><p>Name: $$Record.name$$ ...</div> > }}} > $$ > > Then the value of 'RecordTemplate' is an un-applied anonymous template. > > With something like this, the designer can create a generic page for > displaying a user record. What is needed is a way to invoke another > template with our "anonymous template" as a parameter. And for that > template to invoke the > anonymous template with 'Record' bound to the value it wants to display. > > The concept is entirely similar to first-class functions and higher > order functions. Compare with: > > generic_user_page(Template) -> > Record = get_user(), > [...header..., > Template(Record), > ...footer...]. > > specialized_user_page() -> > RecordTemplate = > case is_admin() of > true -> > fun(Record) -> {form, ..., [{label, ...}, ...]}; > false -> > fun(Record) -> {div, [], {p, [], Record#user.name}} > end. > > If I am vague you must understand that the template language i am > envisioning only exists in my head so far, im pondering > implementations every day to get a coherent side-effect-free and > lazily evaluated language which a web designer can use without > realizing that they are actually programming with such a thing. > > > On 3/8/07, Torbjorn Tornkvist <to...@to...> wrote: >> Christian S wrote: >>> I dont quite understand if you're looking for insight rather than a possible >>> solution. For the problem you describe i would use a yaws SSI, where the yaws >>> file selects the normal-user or the admin-user SSI depending on the session. >> I'm just toying around with the V-part of the MVC concept. >> >> Specifically, I like the idea of being able to let a webdesigner >> work with the HTML/Template/Whatever and prohibit the SW developer >> to affect those parts. >> >> This means that the Webdesigner only deals with values >> like $attr$ et.al, that are supposed to be substitued into the >> resulting HTML. It also means that the SW dev. can't be >> allowed to inject any HTML/etc. >> |