Re: Ignoring the ASP.NET conventions...



"jufemaiz: jc" <euphem...@xxxxxxxxx> wrote in message

news:1182907216.055780.213810@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Is there any information out there on ignoring the desktop oriented
conventions of ASP.NET and developing web app's more in line with
traditional web app development. I need far more control over the x/
html output environment than ASP.NET is currently giving me (coming
from PHP + RoR background) - custom iteration over object groups,
inline controls within those iterators, linking *without* resorting to
client side javascript based form submission, "page as a single form"
desktop application method, mixing of html elements (form) to activate
server side alterations, altering information in the html > head
section of a page directly (there's got to be a way to do this).

Anyone, help?
On Jun 27, 12:29 pm, "clintonG" <nob...@xxxxxxxxxxx> wrote:
I don't understand some of your terminology but here's some insight...

** We can control the output of the XHTML with declarations written into the
web.config file. The same can be done when using Visual Studio 2005.

** Iteration over objects and your other concerns just confused me as stated
but are generally understood as tasks performed with program logic using
your preferred language which common sense and contemporary trends suggests
should now be C#.

** ASP.NET Forms are in fact a single form.

** The head element and all of its contents can be created at will, edited
at will and managed at will using various classes in the framework.

What you need to do is what the rest of us have done: learn more about the
framework. Its humonguos and for awhile the big thing most of us related to
with one another was our mutual experience writing many lines of code when
in fact there was a class with methods in the frasmework mostly already
written for us. That's where you're at now. My best advice? Delve into the
documentation noting the latest ASP.NET documentation is at the subdomain
msdn2.microsoft.com.

Microsoft uses consistent terminology for their documentation and
knowledgebase documents. The word "overview" and other similar word are the
words you want to start with submitted to google or wherever used like
this...

// example 1
page lifecycle overview site:msdn2.microsoft.com

// example 2
htmlmeta class site:msdn2.microsoft.com

// example 3
3.0 site:msdn2.microsoft.com

Once you get the search results when we load one of the references such as
the page for the HtmlMeta class the menu which loads on the left of the page
must be consulted where you can find all other related links to the head
element for example.

You see, for the most part its about learning the correct terminology for
the .NET Framework and then using the documentation that will help you get
through this learning curve...

-
<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URLhttp://clintongallagher.metromilwaukee.com/

Kind of, but not really. Again, from a background in web development
MS appears to have opted to effectively shaft web standards with this
(naming conventions of elements, use of x/html elements as backend
control elements etc)

I'm yet to find any instance of a iterators for output code with the
level of dexterity I want, while attempting some form of separation of
object control code from markup code. I've looked at repeaters, and
that's as close as I can get, but I still can't put inline controls
(if/if-else statements) within the repeater without pulling it away
from the markup code and into the object control code. What is the
model (ala Rails, Django etc's MCV methodology) that ASP.NET follows,
because it seems an incoherent mashup. Not really model focussed, nor
view focussed, nor, really, control focussed, but rather everything
mashed together. The classes you refer to are fine in an environment
where there isn't a great deal of flexibility in controls (read that
as "desktop applications") when compared with x/html elements. I don't
want tables everywhere, I want graceful semantic code.

Again, I want to know why there is the reliance on client side
javascript to activate forms all the time (using the classes etc you
refer to). Also, who in their right mind made an x/html element a
backend control element (the form runat="server") when semantically
forms (plural *or* singular) may not be needed on the page. The
ASP.NET terminology is not designed for the web at all, and nor does
it want its users to actually be educated in web technologies (as I
can see by so many of the questions being asked in this group), the
concept of graceful degradation (or progressive enhancement), real
understanding of the separation of client side behaviour, styling and
markup from server side operations. Sites should *not* rely on
javascript and styling to ensure that they can still be used. Nice to
add in to make it pretty, and to give the user a better experience,
sure, but not absolutely necessary.

The approach is driving me nuts, because of this drag and drop,
wysiwyg, don't understand the fundamentals because "classes will take
care of it" (but if you want something slightly beyond simple tabular
data, or the occasional repeater, and keep code easily understood and
maintainable it seems like the effort required is phenomenal, even for
simple things).

.



Relevant Pages

  • Re: Windows Media Player - Javascript Control in Browser is unpred
    ... I've asked this same question on several Web Video type ... - "you want to control the WMP without the control panel?". ... I have tried to read the documentation but it ... this forum for an answer but often the best way to find an answer is to ...
    (microsoft.public.windowsmedia.sdk)
  • Re: Continuations in Common Lisp (with apologies)
    ... >> Control effects, like side effects, should be documented. ... documentation is part of the software, ... in a language that also has full continuations. ...
    (comp.lang.lisp)
  • Re: Receiving single bytes with MSComm
    ... If you simply take as a premise that MSCOMM is the wrong ... > to locate any documentation in the MSDN. ... If it were an important control, ... > the lack of documentation clearly means this is an inappropriate control). ...
    (microsoft.public.vc.mfc)
  • Re: Ignoring the ASP.NET conventions...
    ... I don't understand some of your terminology but here's some insight... ... ** ASP.NET Forms are in fact a single form. ... documentation noting the latest ASP.NET documentation is at the subdomain ... I need far more control over the x/ ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Basic Separator Line Control
    ... source code documentation. ... "RobinS" wrote: ... If you were the Microsoft employee that created a line control, ... My MSDN Subscription definitely makes me feel better about myself. ...
    (microsoft.public.dotnet.framework.windowsforms)