Re: newbie question

I hope you truly did find my previous post to be informative. After reading
your other posts though, I must go back to one of my original points and
state again that it sounds like you have already convinced yourself not to
use the .NET technologies. Nothing that anyone here can say will change
your mind and honestly, it makes no difference to me if you do or not; it's
your choice.

As much as I hate to quote a fortune cookie here, this discussion seems to
mandate it. The other day I ate lunch at a Chinese restaurant and. My
fortune said "Ignorance never solved any arguments." You have admitted that
you know very little about the technologies yet you are debating the merits
of using them?

I agree with Bill Patterson that these forums are here for getting questions
answered but I also disagree with him in that I believe that a forum such as
this is not the appropriate venue for learning the intracacies of any
technology let alone enough about a technology to determine if it is going
to be the best tool for your job. To determine that you will have to invest
time to actually learn the technology and if you're willing to throw away
'80%' of what you read/learn then so be it. Continuing education is part of
having a technical career and isn't limited to the IT field.

Learning any new technology requires starting from somewhere and while some
technologies directly build upon older technologies, many just utilize and
expand upon the old concepts. Along these lines I submit the question:
How does learning which namespaces to reference in a project differ from
learning which header files to include?

If you think back, I'm sure it took you a significant amount of time to
learn the standard header files in C++. I also bet that during the time you
were learning, you stumbled across something that you had just written code
for and realized "Hey! I wish I knew last week that I could use that!" In
the .NET world, you have the same thing as I just described. They may be
implemented in a different manner but the concept is the same. The same
issue is encountered in the Java world (packages). Is the framework huge?
Absolutely. There is no question that it takes time to learn but doing so
can only serve to help in the long run.

Returning to my original point though, you seem to be looking for someone to
convince you of a need to use the .NET technologies despite having already
concluded that you will not use them. No one here can convince you since
your mind seems to already be made up. If, in your studies, you have a
specific question, ask away but for something as nebulous as what you're
looking for a forum probably isn't your best bet.

Contrary to your closing [Slashdot-esque] statement referencing the Borg,
most people using the .NET technologies have done so not because they are
forced to but because they have evaluated their options and determined that
their needs are best met by what is offered by .NET. The only way that
determination can effectively be reached is through education and some
experimentation. That decision should not be reached just because someone
in a forum said so.

I again wish you luck on your project, no matter what technology you
ultimately choose.
----------------
Dave Fancher
http://davefancher.blogspot.com

"Lisa Pearlson" <no@xxxxxxxx> wrote in message
news:uEeHhMsOFHA.2748@xxxxxxxxxxxxxxxxxxxxxxx
> Thank you for your feedback. I really appreciate it, and I did not dismiss
> anything.
> I'm an experienced C++ programmer. I'm not worried about learning C#.
>
> I do not expect people to support me in my .NET dislike or all other
> layers of abstraction, starting with COM. I understand the advantages, but
> not sure it needs to be that complex. If I wanted to to be affirmed in my
> dislike, I wouldn't be posting on a microsoft news server, but on a linux
> website.
>
> My sole purpose was to learn enough about .NET to know if it can be a
> better tool for the job.. (not only technically, but also market
> acceptance.. if customers want it, and maybe later want connectivity with
> other microsoft products, then using microsoft products is a better
> choice, even if I hate it.. I have to give what the customer wants. I'm
> accepting my miserable fate).
>
> At least I'm not dimissing .NET indefinitely.. For me to judge if it is
> the right tool for the job or not, I need to know enough about it to be
> able to make that judgement, and I don't know enough yet.
>
> Your response has helped me quite a bit.. and I am leaning towards using
> PHP has a draft, and then program a windows C++ application with ODBC.
> Perhaps even embed HTMLView so I can use the ease of web as well as power,
> flexibility and speed of C++.
>
> I'm not done learning about .NET yet though.. If you can't beat them, join
> them.. resistence is futile, we'll all be victimize by this monopoly. :-)
> owwwww
>
> "Dave Fancher" <eijitek@xxxxxxxxxxx> wrote in message
> news:0_ednchVhaEe4M7fRVn-rg@xxxxxxxxxxxxxx
>> For what you have described, ASP.NET doesn't sound like the tool for you.
>> You want a client side technology (ActiveX or Java?) that is able to
>> create and maintain a connection to a database. You don't need ASP.NET
>> for what you have described. I think a desktop application is better
>> suited for this application.
>>
>> To fill you in, the way the event model works in ASP.NET is that each
>> control that triggers a server side event calls a client side JavaScript
>> function that sets the value of a couple of hidden fields then submits
>> the form (a standard HTML form with a runat="server" attribute). There
>> is another hidden field called ViewState that allows for persisting
>> values between server trips. Additionally, each page follows a specific
>> life cycle of events that handle code specific to intialization, loading,
>> event handling, rendering, and unloading.
>>
>> For instance, if you have a Button WebControl (rendered as <input
>> type="button" ...>) that has a server side handler for onClick, the
>> button is also rendered with onclick="__doPostBack(...);" which sets the
>> hidden fields and submits the form. The .NET runtime (on the server)
>> checks the value of the hidden fields (including viewstate) to determine
>> the status of the page and executes the method that is specified to
>> handle the event.
>>
>> The model used by ASP.NET allows for much more managable code not to
>> mention that is succeeds in isolating the logic from the UI code (HTML)
>> since, when done properly with code behinds (VS.NET default), the HTML
>> document (your aspx file) forms the layout for a class ultimately derived
>> from System.Web.UI.Page. With a code behind, you define a class derived
>> from System.Web.UI.Page. When an ASPX is requested, the runtime
>> instantiates a class derived from the class defined in the code behind
>> file.
>>
>> If all your application needs to do is retrieve and edit database
>> records, you may be able to pull this off in a month but that entirely
>> depends on the actual complexity of the app. Overall, the WebControls
>> and HtmlControls are pretty straight forward. ADO.NET is also pretty
>> straight forward. Depending on your environment and application needs
>> though, security considerations (which it sounds like you'll have from
>> your issues over control) offer their own set of complications. Of
>> course, there are nuances to all of these topics about which you should
>> educate yourself.
>>
>> Agreeing with Scott M., IIS is easy to configure. I'm running six
>> ASP.NET apps and have development, testing, and production environments
>> set up for each of them. Very little configuration is needed to properly
>> configure IIS for an ASP.NET application. Granted, IIS configuration is
>> not done through config files but to argue your point about Apache
>> working "out of the box", you said it yourself, "configure some options
>> in a config file, ..., install PHP, ... and off you go." How much does
>> that really differ from "install the .NET Framework, click a button or
>> two to configure some options, and off you go." In either case, you must
>> still create the application folder and tell the HTTP server where the
>> application is loaded.
>>
>> As for learning the .NET technolgies, learning a .NET language shouldn't
>> be a big deal. If all else fails you could even use PerlASPX from
>> ActiveState to allow you to use Perl instead of C#. Sure, there are
>> differences between languages in that some languages offer features that
>> other languages don't but the overall concepts are the same and common
>> constructs are only syntactically different. No matter how it is
>> written, a for loop is still a for loop.
>>
>> When push comes to shove and you're up against a wall, you need to choose
>> the best tool for the job. For your situation, it sounds like you should
>> stick with a tool with which you are already familiar. In fact, your
>> posts read as though you have already convinced yourself not to use the
>> .NET technologies for a variety of reasons that are applicable in some
>> cases and not in others. You seem to be dead-set against using the .NET
>> technologies and are looking for people working in completely different
>> environments with different needs to either validate your concerns
>> (further proving that .NET is not worth your time) or to give you some
>> irrefutable argument as to why you absolutely must use .NET as opposed to
>> the other tools at your disposal. To reiterate, you must evaluate the
>> needs of the project and choose the tool that you believe will best meet
>> those needs. If you believe ASP.NET is the best tool, great, use it,
>> otherwise use something else.
>>
>> On a side note, if you're dismissing at least 80% of what you read, it
>> sounds like you may want to refine your search techniques or perhaps
>> you're simply disregarding too much...
>>
>> Good luck with your project.
>> ----------------
>> Dave Fancher
>> http://davefancher.blogspot.com
>>
>> "Lisa Pearlson" <no@xxxxxxxx> wrote in message
>> news:%23B8LrZlOFHA.1396@xxxxxxxxxxxxxxxxxxxxxxx
>>> Thank you for your response.
>>>
>>> I find that most of my time learning new stuff is wasted on searching
>>> for the right info.. and digging through 80% or more of useless chatter
>>> around it, yet having to read it all to know what is chatter and what is
>>> not.
>>>
>>> If you're a good programmer, you can make applications robust and
>>> scalable without the .NET framework. But since .NET is advertised well
>>> and clueless customers want it, I'm pretty much forced to swallow this
>>> new technology which is yet again another wrapper around all these
>>> microsoft technologies, that I frankly dislike. One reason why I never
>>> liked VB. To much behind the screen wiring.
>>>
>>> Anyway, I should be able to develop something within 1 month, and maybe
>>> fine tune things later.. doing the project will be like following a
>>> tutorial, where I have to search the net for clues as to how to take the
>>> next step. Best way to learn.. But pretty stressful when you have a
>>> deadline too.
>>>
>>> Away from my petty life, back to ASP.NET, you mention "event driven
>>> model".. I'm sure all this info is available on the net, but like I
>>> said, 80% of my time is wasted on searching for it, so this helps me
>>> alot..
>>>
>>>
>>> Question:
>>> How should I understand event driven model in web applications? on
>>> client side, javascript can handle some events, everything else is
>>> usually done via form POST and parsing on the server side, using ASP,
>>> PHP or whatever.
>>> Do events on the client side get sent to the server? Via HTTP messages,
>>> or via DCOM bloat?
>>>
>>>
>>>
>>> I've found so many sources dealing with ASP.NET but none that just
>>> explain some of the basics of what ASP.NET is really all about. I've
>>> read upon some .NET stuff, and it seems little more than a thin wrapper
>>> around windows APIs to handle some garbage collection and such.. (to
>>> use api's you have to write your own wrappers sometimes.. reminds me of
>>> VB, where to do anything useful, required you to import half the windows
>>> api's.. so then why not use VC++ instead, I always wondered).
>>>
>>> Lisa
>>>
>>
>>
>
>


.

Quantcast