boen_robot

I would suggest that you reduce if(strlen($username =< 5) || strlen($username > 15)){echo"Invalid : Username";exit();}if(ereg('[^0-9^A-Za-z]', $username)){echo"Invalid : Username";exit();}...if(ereg('[^0-9^A-Za-z]', $password)){echo"Invalid : Password";exit();} to if(ereg('[^0-9^A-Za-z]', $password) or ereg('^[0-9A-Za-z]{5,15}$', $username)){echo"Invalid username or passowrd";exit();} And also reduce if($checkuser == 0){echo"No user with that name in the db";exit();}if($checkpass->password != $password){echo"Invalid : Password";exit();} to if($checkuser == 0 or $checkpass->password !== $password){echo"Wrong username or password";exit();} The reason is that attackers may try out different usernames and password combinations. If they know what they got right, they can only keep up guessing the other. Keeping the notification general means they'll need more time trying each username with every possible password.Btw, what passowrds exactly do you accept? It seems you have a very broad criteria. You accept every password as long as it begins with an alphanumeric character. This could be your downfall, scince everything else is uncontrollable. Try something like the username for example.

Exactly. And limit the stuff only to what you know the application can handle. In other words: whitelist possibilities.

I'm not sure of the exact meaning, but it practically means "binary". A digit from the binary system that is.A binary digit is either 0 or 1. In machine's logic, this means "there's no electricity" or "there is electricity" respectively. In computer languages, this normally means "false" or "true" respectively.So what I mean by having boolean checks is that a check must have two possible outcomes of one case. A regular expression check may return true in one case and another one, but may also return true where it shouldn't, which is why it must be used with care, especially when dealing with sencetive data like usernames.On the other hand, a hardoded value may only return true in one case and false on everything else, but that's not exactly useful.For example if($user == 'me') will only return true if the $user is 'me'. There's no way to get more secure that that, but that's almost useless. if(ereg('me|you',$user)) will return true only if the $user is 'me' or 'you'. More useful, still secured. However, hardcoding every possible vlaue like that can be very unefficient if you have... let's say 100+ possibilities. Not to mention impossible if you ask for something that can't be known in advance like email for instance.

The only way you can do this without refreshing is JavaScript. But this means that the answer would be inside the source of the page, but also, that users with JavaScript disabled won't be able to view the answers.There are some workarounds for both issues.You can use xmlhttprequest() a.k.a. AJAX to fetch the answer from the server, but the form itself will have to be composed in another form.You can use JavaScript to disable the submit button for the PHP file and/or use alternative button for the AJAX fetch. When JS is disabled, the submit button won't be hidden and/or the other won't be available. This will force the user to refresh the page, but would at least enable him/her to view the answers.

Perhaps<xsl:param name="counter" select="count(/*/presteps) + count(//title)"/>Will give the end count needed.I mean, whatever you're REALLY trying to achieve, it probably has something do to with the sum of all those.And what is your FINAL goal btw?

When there's interaction with a database, there's always risk. The thing is that you are secure when your checks are as boolean as possible. And when you have checks to begin with.If the input is directly used to check up the DB, then it's not secured.If it uses regular expression, security depends on how well the regular expression is.If an input is used in the query only on a certain hardcoded set of values, the form is most secured.

btw, you can also doboolean($BSExists)

I see why you didn't liked my solution... it would only work with PHP5 and Salbotron is only part of PHP4. PHP5's libxslt is faster.

Some sample XML(s) and XSLT would be of great help right now.

I bet it's something small. And it's just the reason why Gobby is just a dream come true . You know sunday's all mine .

You can detect if a certain string (ie a node's content) ends with something by using the ends-with() function. However, scince I don't see this function in any XPath 1.0 reference, suggesting it's only available in XPath 2.0, here's a totally XPath 1.0 alternative: <xsl:variable name="string" select="SECTION"/><xsl:variable name="ends-with" select="'PS'"/><xsl:if test="substring($string,string-length($string) - string-length($ends-with), string-length($ends-with)) = $ends-wtih"><!--the code here will show only if SECTION ends with "PS".--></xsl:if>

DOM results are not saved as arrays. They are saved as DOM objects you then refer to with item(). Values of properties (in the example below, that's "length") are an exclusion to this rule. They are most often strings instead.Try something like $titles = $dom->getElementsByTagName('title');for ($i=0; $i<=$titles->length; $i++){echo $titles->item($i) . '<br>';}

In IE6- yes. But I think (I haven't verified) it works in IE7.

Ever heared of the child and descendant selectors? For example div span matches Anddiv > span matches

Huh? I don't get it. XSLT is for transforming one XML into another (most oftenly XHTML). What do you want to transform and where do you have problems?

Yes, not sure and yes.Yes, a viewer might only show the description of the page with a link to the title, and the look of this description can be controlled by the application. The viewer might also show the contents of the page in the <link/> element.If you edit anything, the user will know there is something new as soon as it checks the feed for updates.There's no way for an application to find out there's a new page without you telling it. And every page that's not "RSS-ed" is considered not to be news, or simply not new.

For the sorting issue, you're on the right track. A choose would be a good idea. Using a variable might be possible in two conditions, but I'm not completely sure about the second.Instead of using a choose for the sort, choose a template to apply. <xsl:sort> can be a direct child of for-each OR apply-templates, making the situation quite fitting: <xsl:param name="sort"/><xsl:template match="/"><xsl:choose><xsl:when test="$sort = 'title'><xsl:apply-templates><xsl:sort select="title"/></xsl:apply-templates></xsl:when><xsl:otherwise><xsl:apply-templates><xsl:sort select="id"/></xsl:apply-templates></xsl:otherwise></xsl:choose></xsl:template> For limiting the number of pictures... what do you think the recordsPerPage parameter in the pagination framework is for? Exactly for that. You can simply use PHP (yes, even 4) to adjust that parameter to whatever you want.For the search, what I showed in that topic might work for fetching the appropriate nodes, however few days ago I realized there's no way (not in XSLT 1 at least) to perform a template around a part of a text node. Because of that, you can't highlight the results or anything. You can just list them.By the way, you HAVE to look into my signature. Gobby to be more precise.

Of course it will. Once the reader makes an update check that is.RSS is only a standart set of elements. It's really up to the reading application to decide how to display the stuff, if/when to update it, etc.

I'm guessing an xref must be converted to equivalent refint element, right?Well, if so, the template <xsl:template match="xref"><xsl:apply-templates/> <xsl:variable name="refidval" select="//xref/@xrefid"/> <xsl:variable name="reftypeval" select="//xref/@xidtype"/><refint refid="{$refidval}" reftype="{$reftypeval}"/></xsl:template> doesn't need to select anything above itself (by using the "//"). Try simply <xsl:template match="xref"><xsl:apply-templates/> <refint refid="{@xrefid}" reftype="{@xidtype}"/></xsl:template> Scince you've got a match attribute, everything inside is selected relatively from that element, eliminating the need for "//".

No thanks needed. It was nothing... I mean really (scince there wasn't anything new for me in the process ).The XSLT FAQ holds the answer to what you seek and it's the JS from question 3 to be exact. If could solve the issues with that script though, it would be good. Whatever the issue with your version, I can tell you that the one one above works with all browsers, as long as of course the XSLT output is fine (try to use document() and run the HTML in Opera to see what I mean).

The fact that you are using XSLT on the server, rather then the client actually gives you a lot of advantages, and form handling is not an exclusion.I would however suggest that you send forms to different ASP.NET files, unless the form is purely controlling the appearance of the page. This would increase: Flexibility - Scince you'll be able to adjust the form controls without worring that an error in them would cause the other parts of the site to fail. Performance - Scince there won't be checks on whether the current query is from a form. Readability - Scince you'll only be looking at the code you need to edit. In a true XForm, you would have to check the raw post data. I don't know how to do that in ASP.NET though. In PHP it's with the $HTTP_RAW_POST_DATA variable.As for how to do it by using FormFaces... I have no idea. I haven't even tryed it out yet. I only tryed a real XForm and I used XSmiles as a browser, scince it's the one of the few user agents with XForms support.By the way, if you use XSLT to form the (X)HTML of the complete page, you can use <xsl:output indent="no"/> to remove all extra whitespace from your output.

WOW. Unless you're using PHP4, I suggest you try out the DOM Functions. They are much easier to set up and debug. Besides, what do you mean by "parse"? With the DOM functions, "parse" would mean "select" but then you'd do something .TIP: Begin with the evaluate() function and after you feel comfortable using XPath, go to query(). Then use item() alongside the rest of the functions to do something with the selected item() from the query() results.

Read the Web Serives tutorial and it's realted ones. They descibe a standart syntax for the exact same principal of "send one XML=>Receive another" you're trying to achieve. By using this standart set, you will ease integration with the server, scince tools already exist and clients would know what to expect.For PHP, see the SOAP functions.

Can I be honest with you? I REALLY don't like the method you're using... First stop, it seems that you're already using more ASP then you need to. All this ASP code adds a lot of crap in the output.Second, what exactly is the transformation? Bad performance could be due to an XSLT file filled with just as much crap.Third, you're not using that much XSLT. Most of the stuff was done in ASP, which kind of kills one of the major points of XSLT - to be portable.As for forms... XForms are the better way, but they are not supported in any browser today without plug-ins, and requiring users to download plug-ins is just not very profitable. Perhaps the JavaScript implementation FormFaces is the way today if you want XForms.If you find ASP's form controls more efficient... go ahead. Until XForms are supported natively by all of the major browsers, there really is not a "best practice" for forms. Not for form sets anyway.

Is it officially out actually? I saw it in a catalog, but haven't really seen a price tag.Anyhow... I'll upgrade to it as soon as it gets cracked and believe me, we're only few days (in the worst case: weeks) from that day. I'm sure, scince I already have MS Office 2007 Enterprice (FINAL).At that point, I'll be probably having an empty HDD from a client buying a new PC, where I'll try it out, without risking anything, check out the new features, etc.When I get the grips on the actual installation- My computers, here I come...