ASPeers, can we agree to stop this shit?



  • <asp:HyperLink Text="Legal" runat="server" CssClass="lbl"  NavigateUrl="~/CMS.aspx?id=11"></asp:HyperLink>
    <asp:Label Text="|" runat="server" ></asp:Label>
    <asp:HyperLink ID="HyperLink1" Text="Privacy" runat="server" CssClass="lbl" NavigateUrl="~/CMS.aspx?id=6"></asp:HyperLink>
    <asp:Label ID="Label1" Text="|" runat="server"></asp:Label>
    <asp:Label Text="&copy; 2012 My Damn Company, LLC. All rights reserved." runat="server" Style="padding-right: 28px; color: #7B7B7B;"></asp:Label>

     Learn some fucking HTML, bitch.

    What is wrong with this?

    <a href="~/CMS.aspx?id=11" class="lbl">Legal</a> | <a href="~/CMS.aspx?id=6" class="lbl">Privacy</a> | &copy; 2013 My Damn Company, LLC. All rights reserved.

    Seriously, who is teaching that first style? I see it way too much.



  • ASP is dynamic and who knows if you might need to change that label in the future. So you should always should stick to ASP. See?



  • @jasmine2501 said:

    <asp:HyperLink Text="Legal" runat="server" CssClass="lbl"  NavigateUrl="~/CMS.aspx?id=11"></asp:HyperLink>
    <asp:Label Text="|" runat="server" ></asp:Label>
    <asp:HyperLink ID="HyperLink1" Text="Privacy" runat="server" CssClass="lbl" NavigateUrl="~/CMS.aspx?id=6"></asp:HyperLink>
    <asp:Label ID="Label1" Text="|" runat="server"></asp:Label>
    <asp:Label Text="&copy; 2012 My Damn Company, LLC. All rights reserved." runat="server" Style="padding-right: 28px; color: #7B7B7B;"></asp:Label>

     Learn some fucking HTML, bitch.

    What is wrong with this?

    <a href="~/CMS.aspx?id=11" class="lbl">Legal</a> | <a href="~/CMS.aspx?id=6" class="lbl">Privacy</a> | &copy; 2013 My Damn Company, LLC. All rights reserved.

    Seriously, who is teaching that first style? I see it way too much.

    Agreed, a lot of asp.net to not add value to html. Of course, if you were gonna add some i18n, then it would be not-so-useless.



  • My ASP.net instructor actually brought this up as a ridiculous waste of resources when she covered the use of Literal, Label, and HyperLink. Kinda like using php's echo for every single line of static HTML in your files; completely obliterates the biggest advantage of these, which is the ability to only use it where you need it.


  • Trolleybus Mechanic

    @jasmine2501 said:

    <a href="~/CMS.aspx?id=11" class="lbl">Legal</a>
     

    I'll have to check when I get to work, but I didn't think the ~/ would expand unless it was runat="server"

    Second the point on i8nl.

    Third, why not make it even more readable with <asp:Hyperlink ... /> ?

    Fourth, if you're going to go .Net, go whole hog!  Put those menu items into a database, and bind it to an asp:Repeater.

    Sixth, why is your last label not CssClass="lbl"?  Adding all that style adds, like, 20 bytes to your page! EVERY PAGE!

    Seventh: I don't know if I'm trolling or helping. I kinda fell off message halfway through my points. Go suck a purple dildo. Suck it WITH YOUR ARMPIT!



  • Correct, ~ won't resolve on older ASP.NET. I agree you don't need a Label control for the static stuff: kind of like your own sig, for example :)



  • It's the ASP.NET version of the classic ASP pattern which I have seen and shuddered at:

    Response.Write("<html>")
    Response.Write("<head>")
    Response.Write("<title>My pile of WTF</title>")
    /* snip ... */
    Response.Write("</html>")
    


  • Could also be an ASP newbie just using drag-and-drop and the Properties window in the forms designer.



  • @Lorne Kates said:

    @jasmine2501 said:

    <a href="~/CMS.aspx?id=11" class="lbl">Legal</a>
     

    I'll have to check when I get to work, but I didn't think the ~/ would expand unless it was runat="server"

    Second the point on i8nl.

    Third, why not make it even more readable with <asp:Hyperlink ... /> ?

    Fourth, if you're going to go .Net, go whole hog!  Put those menu items into a database, and bind it to an asp:Repeater.

    Sixth, why is your last label not CssClass="lbl"?  Adding all that style adds, like, 20 bytes to your page! EVERY PAGE!

    Seventh: I don't know if I'm trolling or helping. I kinda fell off message halfway through my points. Go suck a purple dildo. Suck it WITH YOUR ARMPIT!


    Now we just have to know what the 5th point was!!! I'm sure it was the most important!



  • @mott555 said:

    Could also be an ASP newbie just using drag-and-drop and the Properties window in the forms designer.

    ... And they go into the form because they were too fucking lazy to move the insertion point after creating a new page?

    Yeah, I can totally see that.


  • Trolleybus Mechanic

    @Julia said:

    It's the ASP.NET version of the classic ASP pattern which I have seen and shuddered at:

    Response.Write("<html>")
    Response.Write("<head>")
    Response.Write("<title>My pile of WTF</title>")
    /* snip ... */
    Response.Write("</html>")
    

     

    My favorite is how that all comes out as a single line with no line breaks, indents or whitespace. Makes the HTML super readable.

    Though in ASP.Net, the new, hipper, cooler pattern is to do this:


    <asp:Form runat="server" id="Form1">
    <asp:Literal id="litHTML" /> 
    </asp:Form>

    Then in the codebehind (in PageLoad, of course, because Page_PreRender isn't autogenerated by VS)... usually inside a DataReader loop:

    litHTML.Text = litHTML.Text & "<input type=" & Chr(34) & "text" & Chr(34) & name=" & Chr(34) & "IDoNotKnowWhatAnIDIs" & Chr(34) & " />"
    ...

    And later, of course, looking at Request.Form("IDoNotKnowWhatAnIDIs") directly.

    But you see, it's using .Net controls, so its okay. {twitch}

    And don't get me started with <body onload="javascript:document.write('<form>..........</form>')">

     



  • @Julia said:

    It's the ASP.NET version of the classic ASP pattern which I have seen and shuddered at:

    Response.Write("<html>")
    Response.Write("<head>")
    Response.Write("<title>My pile of WTF</title>")
    /* snip ... */
    Response.Write("</html>")
    

    I've seen entire files written like this:

    <html>
    <head>
    <% Response.Write("<title>...</title>"); %>
    <% Response.Write("<link ...>"); %>
    <script>
    ...
    </script>
    </head>
    <body>
    <% Response.Write("<h1>title</h1>"); %>
    <% Response.Write("<p>"); %>
    contents
    <% Response.Write("</p>"); %>
    </body>
    </html>
    

    There was no actual code in the asp other than Response.Write and a few includes.



  • @configurator said:

    I've seen entire files written like this:

    <html>
    <head>
    <% Response.Write("<title>...</title>"); %>
    <% Response.Write("<link ...>"); %>
    <script>
    ...
    </script>
    </head>
    <body>
    <% Response.Write("<h1>title</h1>"); %>
    <% Response.Write("<p>"); %>
    contents
    <% Response.Write("</p>"); %>
    </body>
    </html>
    

    There was no actual code in the asp other than Response.Write and a few includes.





    I once had a class that had a 12,000 line method:

    public string BuildBody()
    {
        string body = "";
        body += "<html>";
        body += "<head>";
        
         // snip 12000 lines ...
        body += "</html>";
        
        return body;
    }
    

    And then of course just Response.Write the method on the page.
    The code had been inherited when my company acquired another one, so I never met the guy, but he was responsible for literally 100s of WTFs (such as trying to use NBSPs to center text on the page). My favorite part was the 20 line copyright statement he had at the top of every code file like people were just dying to steal his steaming pile of crap.


  • Although, the style of that code leaves a lot to be desired, you are mistaken when it comes to asp:hyperlinks. I just hope all your users have cookies enabled... if they don't and you have been using naked <a>s your users won't be able to maintain a session...
    Also the ability to use ~ in urls is very useful, at least in my opinion.

    But ya that use of labels is excessive.

    My biggest issue is if your tag has no content, just write <asp:Label runat="server" />  



  • And people say this is better then PHP.



  • I have been doing some php work and it's driving me crazy!

    The amount of features missing is ridiculous. Serverside redirects, nope! Threading nope!


  • Considered Harmful

    @this_code_sucks said:

    Although, the style of that code leaves a lot to be desired, you are mistaken when it comes to asp:hyperlinks. I just hope all your users have cookies enabled... if they don't and you have been using naked <a>s your users won't be able to maintain a session...
    Also the ability to use ~ in urls is very useful, at least in my opinion.

    But ya that use of labels is excessive.

    My biggest issue is if your tag has no content, just write <asp:Label runat="server" />  

    Just. I don't know where to begin.



  • I once had a Classic ASP job (in 2006, using FoxPro 2.6 databases for everything) where the MIS Director insisted on using Response.Write for everything, because he read somewhere that it was faster since the <%= %> stuff was interpreted into Response.Write calls anyways.  He also used no IDE and preferred Notepad even though we had Visual InterDev or w/e the VB6 web development IDE was called.  I found Notepad++ and fell in love with it.  As you may have guessed, his parents owned the company and he became MIS director immediately after graduating from college, no experience required.

    Fun times.  Not really.

    About the OP's WTF: Many ASP.NET WebForms developers go way overboard with server-side controls and have no concept of HTML at all.  Everything is some kind of widget, which mimics WebForms' original purpose as a way to get WinForms devs to write apps for the web.  Of course you don't need it if you're just putting static text in, but a lot of guys don't know that.



  • What drives me nuts about PHP is fucking php.ini. Settings for each application? RIDICULOUS! You must have ONE settings file that applies to the ENTIRE SERVER! It's unpossible for one application to have different settings from another, yet be running on the same server! What is this, Star Trek?!?

    And also: it's an .ini file. In 2013. Oh and it doesn't follow the standard .ini parsing rules, of course. So it's a broken .ini file.

    I like to think that if the PHP lead developers ever learned how the IIS + ASP ecosystem worked, their heads would explode.



  • @blakeyrat said:

    What drives me nuts about PHP is fucking php.ini. Settings for each application? RIDICULOUS! You must have ONE settings file that applies to the ENTIRE SERVER!
     

    No, it doesn't.

     

     


  • Discourse touched me in a no-no place

    @Cassidy said:

    No, it doesn't.
    Stop quoting true stuff - you know how it sets him off when you prove he's wrong.


  • Trolleybus Mechanic

    @PJH said:

    @Cassidy said:
    No, it doesn't.
    Stop quoting true stuff - you know how it sets him off when you prove he's wrong.
     

    That's true.



  • @Lorne Kates said:

    @PJH said:
    Stop quoting true stuff - you know how it sets him off when you prove he's wrong.
    That's true.
     

    Bugger... I've been trolled again, ain't I?

     



  • @joe.edwards said:

    @this_code_sucks said:

    Although, the style of that code leaves a lot to be desired, you are mistaken when it comes to asp:hyperlinks. I just hope all your users have cookies enabled... if they don't and you have been using naked <a>s your users won't be able to maintain a session...
    Also the ability to use ~ in urls is very useful, at least in my opinion.

    But ya that use of labels is excessive.

    My biggest issue is if your tag has no content, just write <asp:Label runat="server" />  

    Just. I don't know where to begin.



    Maybe a numbered list? If I'm mistaken I'd like to know so I don't make the same mistakes in the future.


  • Considered Harmful

    @this_code_sucks said:

    Maybe a numbered list?

    OK, not using self-closing syntax on controls pales in comparison to the following WTFs:

    1. Label elements semantically label form fields. Nothing else. If you use them for random text output, you are doing it wrong. Consider asp:Literal
    2. In this case, the text of the label is statically "|", so no i18n argument is even valid here. How do you translate "|"? There is no reason to use a server control here whatsoever.
    3. While your argument that links fail to hold session state without cookies enabled may have some validity, however, I'd recommend avoiding session state if at all possible (and I've never run into a case where it wasn't possible in over a decade of professional web development) because:
      1. It violates the general statelessness of the web, usually leading to sites that cannot be browsed in multiple tabs at once
      2. The default session state in ASP.NET is InProc, which bloats server memory and cannot be shared in a server farm/load balanced/cloud environment. And if you're writing code like this, you wouldn't have changed it to use a state server or SQL Server.
      3. Session state is often abused as a bucket o' global variables shared by the site and generally promotes bad coding style on the server-side.
    4. These controls actually contribute to ViewState (unless you go out of your way to disable that), which if not kept carefully in check leads to a big 1MB+ blob of base64 in a hidden form field on your page. This slows down the server, hurts SEO, and increases load time.
    5. Inline styles are being used which will make a site redesign take a couple orders of magnitude more effort, and generally bloat and pollute the markup.
    6. The URL of CMS.aspx?id=6 yields zero information to either user or search engine. Look at that URL in your browser history and tell me where it goes. Why does the user need to know it's .aspx, or for that matter the ID of the page? It's an implementation detail. What if the platform changes, will all the bookmarked links and inbound links break (hint: yes)?

    In short, this coding style is awful. The rendered output is large, semantically incorrect, search-engine hostile, there's no separation of presentation from document structure, it increases both bandwidth and server load unnecessarily, and if session state is being used then separate tabs can interact in strange ways. This is almost as bad as using postbacks (asp:Buttons and asp:LinkButtons) for navigation - just don't do it.



  • @joe.edwards said:

    @this_code_sucks said:
    Maybe a numbered list?

    OK, not using self-closing syntax on controls pales in comparison to the following WTFs:

    1. Label elements semantically label form fields. Nothing else. If you use them for random text output, you are doing it wrong. Consider asp:Literal
    2. In this case, the text of the label is statically "|", so no i18n argument is even valid here. How do you translate "|"? There is no reason to use a server control here whatsoever.
    3. While your argument that links fail to hold session state without cookies enabled may have some validity, however, I'd recommend avoiding session state if at all possible (and I've never run into a case where it wasn't possible in over a decade of professional web development) because:
      1. It violates the general statelessness of the web, usually leading to sites that cannot be browsed in multiple tabs at once
      2. The default session state in ASP.NET is InProc, which bloats server memory and cannot be shared in a server farm/load balanced/cloud environment. And if you're writing code like this, you wouldn't have changed it to use a state server or SQL Server.
      3. Session state is often abused as a bucket o' global variables shared by the site and generally promotes bad coding style on the server-side.
    4. These controls actually contribute to ViewState (unless you go out of your way to disable that), which if not kept carefully in check leads to a big 1MB+ blob of base64 in a hidden form field on your page. This slows down the server, hurts SEO, and increases load time.
    5. Inline styles are being used which will make a site redesign take a couple orders of magnitude more effort, and generally bloat and pollute the markup.
    6. The URL of CMS.aspx?id=6 yields zero information to either user or search engine. Look at that URL in your browser history and tell me where it goes. Why does the user need to know it's .aspx, or for that matter the ID of the page? It's an implementation detail. What if the platform changes, will all the bookmarked links and inbound links break (hint: yes)?

    In short, this coding style is awful. The rendered output is large, semantically incorrect, search-engine hostile, there's no separation of presentation from document structure, it increases both bandwidth and server load unnecessarily, and if session state is being used then separate tabs can interact in strange ways. This is almost as bad as using postbacks (asp:Buttons and asp:LinkButtons) for navigation - just don't do it.



    Your points are valid. I was being a bit sarcastic when saying the closing style bothered me the most.

    I agree with you 100% on session state, I forget the exact thread, but I basically said the same thing in another thread. However, just because you are not using session state doesn't mean you don't need to hold a session for identification/authorization purposes.

    Also, when it comes to viewstate, parsing of the markup occurs inbetween preinit and init, this is before viewstate is turned on. Therefore, as bad as this markup is, it will not cause viewstate bloat. 

  • Considered Harmful

    @this_code_sucks said:

    Also, when it comes to viewstate, parsing of the markup occurs inbetween preinit and init, this is before viewstate is turned on. Therefore, as bad as this markup is, it will not cause viewstate bloat. 

    Viewstate is used eg to determine whether the text in a text field has changed since the last page load to know to fire off the TextChanged event, or to maintain changes in values done from the codebehind. I'm not in a place where I can test to verify whether a statically defined control contributes to it, but I've definitely dealt with runaway ViewState, and when I decoded it, maybe 1/20th of it was actually data that needed to be persisted. Try using a decoding tool on your Viewstate sometime, you might be surprised how much worthless information is being passed around. I've seen it approach a meg of data on pages that weren't even posting back, completely useless!

    Edit: actually, I know for a fact there are WebControls that do this:

    public string SomeProperty {
      get { return (string)ViewState[ "SomeProperty" ]; }
      set { ViewState[ "SomeProperty" ] = value; }
    }
    

    So I very much doubt that's correct.


  • Considered Harmful

    Verified, with Red Gate .NET Reflector:

    @System.Web.UI.WebControls.Label said:
    [PersistenceMode(PersistenceMode.InnerDefaultProperty), WebSysDescription("Label_Text"), Localizable(true), Bindable(true), WebCategory("Appearance"), DefaultValue("")]
    public virtual string Text
    {
        get
        {
            object obj2 = this.ViewState["Text"];
            if (obj2 != null)
            {
                return (string) obj2;
            }
            return string.Empty;
        }
        set
        {
            if (this.HasControls())
            {
                this.Controls.Clear();
            }
            this.ViewState["Text"] = value;
        }
    }
    


  • I've been using dotPeek even since Redgate deleted it's own software off my hard drive. Also it apparently figured out the ?? operator in that code too.



  • @joe.edwards said:

    Verified, with Red Gate .NET Reflector:


    @System.Web.UI.WebControls.Label said:
    [PersistenceMode(PersistenceMode.InnerDefaultProperty), WebSysDescription("Label_Text"), Localizable(true), Bindable(true), WebCategory("Appearance"), DefaultValue("")]
    public virtual string Text
    {
    get
    {
    object obj2 = this.ViewState["Text"];
    if (obj2 != null)
    {
    return (string) obj2;
    }
    return string.Empty;
    }
    set
    {
    if (this.HasControls())
    {
    this.Controls.Clear();
    }
    this.ViewState["Text"] = value;
    }
    }



     It doesn't matter if you assign somthing to viewstate, prior to it being "turned on" it will NOT be persisted and will therefore only last during the course of the request. I have never had an issue with viewstate bloat in pages I have written myself.

    Try this experiment, put the following code in the page_init event (before viewstate starts saving) then do a post and see if the value is still there in the second request:

    if (this.IsPostBack)
                {
                    ViewState["foo"] = "TESTING";
                }
                else
                {
                    string iWillBeNull = (string)ViewState["foo"];
                }



  • @this_code_sucks said:

    @joe.edwards said:

    Verified, with Red Gate .NET Reflector:


    @System.Web.UI.WebControls.Label said:
    [PersistenceMode(PersistenceMode.InnerDefaultProperty), WebSysDescription("Label_Text"), Localizable(true), Bindable(true), WebCategory("Appearance"), DefaultValue("")]
    public virtual string Text
    {
    get
    {
    object obj2 = this.ViewState["Text"];
    if (obj2 != null)
    {
    return (string) obj2;
    }
    return string.Empty;
    }
    set
    {
    if (this.HasControls())
    {
    this.Controls.Clear();
    }
    this.ViewState["Text"] = value;
    }
    }



     It doesn't matter if you assign somthing to viewstate, prior to it being "turned on" it will NOT be persisted and will therefore only last during the course of the request. I have never had an issue with viewstate bloat in pages I have written myself.

    Try this experiment, put the following code in the page_init event (before viewstate starts saving) then do a post and see if the value is still there in the second request:

    if (this.IsPostBack)
                {
                    ViewState["foo"] = "TESTING";
                }
                else
                {
                    string iWillBeNull = (string)ViewState["foo"];
                }

    forgot the ! in the if statement



  • You never know when you'll need to localize "|"



  • @Ben L. said:

    You never know when you'll need to localize "|"

    True. People said the same thing about "\" but then the Japanese went and turned out paths like C:¥Program Files¥.



  • @this_code_sucks said:

    Serverside redirects, nope!
    Server-side redirects, [url=http://php.net/manual/en/function.header.php]yep[/url]. Go take an Internet for Dummies class so you can learn to use Google.



  • @MiffTheFox said:

    People said the same thing about "" but then the Japanese went and turned out paths like C:¥Program Files¥.
    That reminds me of C:ĐDOS>



  • @MiffTheFox said:

    @Ben L. said:
    You never know when you'll need to localize "|"

    True. People said the same thing about "\" but then the Japanese went and turned out paths like C:¥Program Files¥.

    Iirc that's a codepage problem; internally its the same byte representation. Funny how pre-unicode environments work, no?

     



  • @Sir Twist said:

    @this_code_sucks said:

    Serverside redirects, nope!
    Server-side redirects, yep. Go take an Internet for Dummies class so you can learn to use Google.

    <font size="3" face="Times New Roman">

    </font>

    <font size="3"><font face="Calibri">I’m not sure if you are just a vindictive moron or I was not being
    clear on what I meant by server side redirect. You seem like a cool guy so I
    will go with the latter. What you linked to is still a client side redirect; it
    is just triggered server side.  See you
    are putting the redirect instruction in the RESPONSE headers. Since it’s in the
    response it still relies on the client’s browser to perform the redirect. I was
    referring to a redirect that takes place entirely on the server, like
    Server.Transfer in asp.net; PHP does not have an equivalent function. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></font></font>

    <font size="3" face="Times New Roman">

    </font>


  • Considered Harmful

    @this_code_sucks said:

    PHP does not have an equivalent function.

    May be true (I'm no PHP guru), but PHP is usually part of a LAMP stack where mod_rewrite can do much the same thing.

    Out of curiosity, why is Server.Transfer functionality useful? I've not seen a solid use-case for it (except URL rewriting/routing, which there are better APIs for), and I'd like to know what scenarios you'd consider it appropriate for.



  • @joe.edwards said:

    Server.Transfer
     

    AFAIK, retains application/program state.

    Redirect dumps everything and starts afresh with the new page.



  • @this_code_sucks said:

    I’m not sure if you are just a vindictive moron or I was not being
    clear on what I meant by server side redirect. You seem like a cool guy so I
    will go with the latter. What you linked to is still a client side redirect; it
    is just triggered server side.  See you
    are putting the redirect instruction in the RESPONSE headers. Since it’s in the
    response it still relies on the client’s browser to perform the redirect. I was
    referring to a redirect that takes place entirely on the server, like
    Server.Transfer in asp.net; PHP does not have an equivalent function.

    require '404.php'; die;

     

    Public Service Announcement

    PHP by itself in only along the lines of ASP by itself. To make it really useful, you have to add a library like CakePHP, just like to make ASP really useful, you have to add WebForms or ASP.NET MVC.

    The more you knooooooooowww!



  • @joe.edwards said:

    @this_code_sucks said:
    Maybe a numbered list?

    OK, not using self-closing syntax on controls pales in comparison to the following WTFs:

    1. Label elements semantically label form fields. Nothing else. If you use them for random text output, you are doing it wrong. Consider asp:Literal
    2. In this case, the text of the label is statically "|", so no i18n argument is even valid here. How do you translate "|"? There is no reason to use a server control here whatsoever.
    3. While your argument that links fail to hold session state without cookies enabled may have some validity, however, I'd recommend avoiding session state if at all possible (and I've never run into a case where it wasn't possible in over a decade of professional web development) because:
      1. It violates the general statelessness of the web, usually leading to sites that cannot be browsed in multiple tabs at once
      2. The default session state in ASP.NET is InProc, which bloats server memory and cannot be shared in a server farm/load balanced/cloud environment. And if you're writing code like this, you wouldn't have changed it to use a state server or SQL Server.
      3. Session state is often abused as a bucket o' global variables shared by the site and generally promotes bad coding style on the server-side.
    4. These controls actually contribute to ViewState (unless you go out of your way to disable that), which if not kept carefully in check leads to a big 1MB+ blob of base64 in a hidden form field on your page. This slows down the server, hurts SEO, and increases load time.
    5. Inline styles are being used which will make a site redesign take a couple orders of magnitude more effort, and generally bloat and pollute the markup.
    6. The URL of CMS.aspx?id=6 yields zero information to either user or search engine. Look at that URL in your browser history and tell me where it goes. Why does the user need to know it's .aspx, or for that matter the ID of the page? It's an implementation detail. What if the platform changes, will all the bookmarked links and inbound links break (hint: yes)?

    In short, this coding style is awful. The rendered output is large, semantically incorrect, search-engine hostile, there's no separation of presentation from document structure, it increases both bandwidth and server load unnecessarily, and if session state is being used then separate tabs can interact in strange ways. This is almost as bad as using postbacks (asp:Buttons and asp:LinkButtons) for navigation - just don't do it.

    Agreed. And really, I don't care about the users who disable cookies - they are having a weird web experience everywhere.

    Sorry I couldn't respond to this, I got in a car accident about an hour after I posted it!



  •  Yes, I googled what you said, not what you meant. Elsewhere, others have also shown multiple ways to to accomplish the equivalent to Server.Transfer.



  • @dhromed said:

    @joe.edwards said:

    Server.Transfer
     

    AFAIK, retains application/program state.

     

    Probably mod_rewrite, then. Dunno if it can be called via PHP, but I use it in Apache quite a bit.

     



  • @MiffTheFox said:

    @this_code_sucks said:
    I’m not sure if you are just a vindictive moron or I was not being clear on what I meant by server side redirect. You seem like a cool guy so I will go with the latter. What you linked to is still a client side redirect; it is just triggered server side.  See you are putting the redirect instruction in the RESPONSE headers. Since it’s in the response it still relies on the client’s browser to perform the redirect. I was referring to a redirect that takes place entirely on the server, like Server.Transfer in asp.net; PHP does not have an equivalent function.
    require '404.php'; die;

    Public Service Announcement

    PHP by itself in only along the lines of ASP by itself. To make it really useful, you have to add a library like CakePHP, just like to make ASP really useful, you have to add WebForms or ASP.NET MVC.

    The more you knooooooooowww!

    So if I have require 'http://google.com' it will return the google home page?

    I am using Zend Framework, so far I am not impressed...



  • @Cassidy said:

    Probably mod_rewrite, then. Dunno if it can be called via PHP, but I use it in Apache quite a bit.
     

    AFAIK (2) mod_rewrite processes the http request before php has gotten any chance of looking at it, which makes it intrinsically impossible to retain program state, since there's no program code executed yet.

    So, no, mod_rewrite != Server.Transfer

    If that's what you were saying, I mean.

    If not, then yoOH COOKIES YAAAAYYYY



  • @jasmine2501 said:

    @joe.edwards said:
    @this_code_sucks said:
    Maybe a numbered list?

    OK, not using self-closing syntax on controls pales in comparison to the following WTFs:

    1. Label elements semantically label form fields. Nothing else. If you use them for random text output, you are doing it wrong. Consider asp:Literal
    2. In this case, the text of the label is statically "|", so no i18n argument is even valid here. How do you translate "|"? There is no reason to use a server control here whatsoever.
    3. While your argument that links fail to hold session state without cookies enabled may have some validity, however, I'd recommend avoiding session state if at all possible (and I've never run into a case where it wasn't possible in over a decade of professional web development) because:
      1. It violates the general statelessness of the web, usually leading to sites that cannot be browsed in multiple tabs at once
      2. The default session state in ASP.NET is InProc, which bloats server memory and cannot be shared in a server farm/load balanced/cloud environment. And if you're writing code like this, you wouldn't have changed it to use a state server or SQL Server.
      3. Session state is often abused as a bucket o' global variables shared by the site and generally promotes bad coding style on the server-side.
    4. These controls actually contribute to ViewState (unless you go out of your way to disable that), which if not kept carefully in check leads to a big 1MB+ blob of base64 in a hidden form field on your page. This slows down the server, hurts SEO, and increases load time.
    5. Inline styles are being used which will make a site redesign take a couple orders of magnitude more effort, and generally bloat and pollute the markup.
    6. The URL of CMS.aspx?id=6 yields zero information to either user or search engine. Look at that URL in your browser history and tell me where it goes. Why does the user need to know it's .aspx, or for that matter the ID of the page? It's an implementation detail. What if the platform changes, will all the bookmarked links and inbound links break (hint: yes)?

    In short, this coding style is awful. The rendered output is large, semantically incorrect, search-engine hostile, there's no separation of presentation from document structure, it increases both bandwidth and server load unnecessarily, and if session state is being used then separate tabs can interact in strange ways. This is almost as bad as using postbacks (asp:Buttons and asp:LinkButtons) for navigation - just don't do it.

    Agreed. And really, I don't care about the users who disable cookies - they are having a weird web experience everywhere.

    Sorry I couldn't respond to this, I got in a car accident about an hour after I posted it!




    I guess your users are not government hahaha

    Hope everyone's okay! How bad is the damage? 



  • @this_code_sucks said:

    So if I have require 'http://google.com' it will return the google home page?

    Yep! Transparent access to network resources as files via URIs! <3

    (Although if you want to prevent any PHP in the result from google.com being parsed, you can use print file_get_contents('http://google.com'), but that still presents the problem of if Google gets dns-hijacked on your network, the attacker can serve anything they want to the user.)

     

    (Also note that this is not a PHP-specific security flaw. In C#, you can just as easily do Response.Write((new WebClient()).DownloadString("http://google.com")).



  • @this_code_sucks said:

    I guess your users are not government hahaha

    Hope everyone's okay! How bad is the damage? 

    No they are lawyers, I don't know if that's worse or better. My car is totaled, but nobody was hurt. It's really amazing how safe today's cars are - in the 70s, people would have died in a crash like this. I had full coverage so I'll be getting a check for $2400, which should be a good start on a new car. I was getting ready to buy a new car anyway, but I didn't need this kind of motivation! Driving my mom's truck sucks :)


  • Trolleybus Mechanic

    @jasmine2501 said:

    Driving my mom's truck sucks
     

    I know you're in a tough spot now, so I'll give you a free pass. You better appreciate exactly how much comedic potential I'm giving up with this one sentence. 



  •  Oh my god, you guys are fucking hitting on her.


Log in to reply