boen_robot
-
Posts
8,493 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Events
Everything posted by boen_robot
-
I have no idea what theese coding camps are actually. Those things you wrote sound more like kinds of mobile networks, which is quite different.If users get sticked by security issues, they won't give you a second chance. If you are going to make a credit card payment, it HAS to include an SSL encryption from the first time. It's not the "XHTML" which has to be secure. It's the HTTP protocol, but that's just a detail. A phone payment won't requre this though, scince everything is done inside the operator's system.By the way, I don't get it.... how can you possibly organize a payment that would not requre a computer at all? How can anyone preview the thing he/she wants properly? And most importantly: How are they going to pay?There are only 2 ways I can think of:1. SMS payment. A user memorizes some code and types it as an SMS to an appropriate number for the appropriate price.2. Traffic payment. The payment is done when the user clicks on a download button and his internet bill gets extra charged with the appropriate price.In both ways: you need operator's support. The more- the better.If there was one central operator (the same way there's ICANN for the world wide web), there would be ONLY mobile phone payments .
-
The HTML tutorial on W3Schools is based on HTML 4.01, so this means you already know it. Move to XHTML and CSS now. Most of the advanced part in the HTML tutorial doesn't contain anything useful.
-
The codediv.p {CSS properties here} Will apply the CSS properties to all divs in the (X)HTML who look like this: <div class="p">Some content to be styled</div><div>But this content won't, because it doesn't have a class p.</div> And a code in the CSS which looks like this: div p {CSS properties here} Will apply the styles to all p elements inside div ones, like this: <p>This content is not going to be styled.</p><div>This content is not be styled either, but <p>this one will, because this p element is inside a div.</p><div> Following the above logic, the code: div, p {CSS properties here} Will style both div and p elements. Example: <p>This element is going to be styled</p><div>And this one too</div>
-
That's not exactly right. Here yo go:div.p = styles every div with class p.div p = styles all p's contained within a div only.div, p = styles all div and p's
-
If you mean that the systax of XML is colored, well... yes it is. They already told you XML is different then XHTML. And XML files without stylesheets applyed to them leave to the browser to decide how to make them look. IE automatically applyes it's systax coloring for previewing purposes, but it doesn't allow you to edit the source directly and (as you have noticed) it hides some parts (such as the doctype).
-
Why don't you group all the things in the XML file and access them separatly. Example: <people><person><fname>Allan</fname><lname>Rogers</lname></person><person><fname>Madonna</fname></person><person><fname>Peter</fname><lname>Smith</lname></person></people>
-
True, I admit this is a very "boring like" system. It's normal that you don't care that much for security, but a large varaity of users does, so you should compile with their needs.An SMS payment did came into my mind, however, it would probably cover only one country (Norway?) and perhaps with later investments, one or two more countries. I don't think it would work as international kind of payment. If you could make an international SMS payment system that would be supported by all mobile operators and would be on internationally acceptable prizes, you'll be a world hit.
-
Well, the easiest way I can think of is to archive (zip) your videos, so the users would be forced to download them first. If you want them to save raw movies, then... I don't think there's a way. It's all user's settings. At least, I think it's only that though.
-
<xsl:stylesheet version="1.0"xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:template match="/"><html><body> <h2>My note</h2> <xsl:apply-templates select="note/subject"/></body></html></xsl:template> <xsl:template match="note/subject"> <p> <xsl:apply-templates select="tag1"/> <xsl:apply-templates select="tag4"/> </p> </xsl:template> <xsl:template match="tag1"> Topic: <xsl:value-of select="."/><br/> </xsl:template> <xsl:template match="tag4"> <xsl:for-each select="."> <xsl:apply-templates select="tag2" /> <xsl:apply-templates select="contents/tag3" /> </xsl:for-each> </xsl:template> <xsl:template match="tag2"> Title: <span style="color:#ff0000"> <xsl:value-of select="."/></span> <br /> </xsl:template> <xsl:template match="contents/tag3"> <xsl:for-each select="."> <xsl:choose> <xsl:when test="tag5"> <a> <xsl:attribute name="href"> <xsl:value-of select="tag5" /> </xsl:attribute> <xsl:value-of select="tag6" /> </a><br/> </xsl:when> <xsl:otherwise> Content: <span style="color:#00f000"> <xsl:value-of select="."/> </span> <br/> </xsl:otherwise> </xsl:choose> </xsl:for-each> </xsl:template></xsl:stylesheet> I decided to take the code into my lab (Dreamwaver 8) for further investigation and this is what I got in the end. As I suspected, it's all wrong XPath expressions and nothing more. The XPath expression in the root ("/") template is optional btw. I put it just to ensure all is OK. I also added some "for-each"es, to ensure that not only the first record is shown .Btw, try to use the BBCode element to mark your code. It's easier to read and copy(for investigation) that way.
-
I don't want to repeat myself so here is a review from myself and my opinion for what server side language might be called the best. Still: outside factors such as hosting plans, support, etc. are thing you have to consider.
-
Well, when there's no alternative, a JavaScript is acceptable, but in the case of hr it's useless. And don't worry about the target replacement too. CSS3 is going to have a target property for opening links in new windows or tabs. It's just a matter of time until browsers support it though. Until then: DOM rules the world .
-
Mostly for accesability purposes. For example, if you use an emty div to clear floats in the body and start arranging the footer. A hr would be better because when viewed without the CSS file (example: text browsers, tuned off CSS by the user, etc.) it gives a nice horizontal line, dividing the body and the footer.Also, a purpose of the div is to hold different parts of a page. The purpose of hr is to devision between those different sections. In short: again comes the spirit of web standarts.
-
It depends. If the JavaScipt is stored inside an XML file, then the code would be something like:<script><xsl:value-of select="XPath expression to the script" /></script>Or if you want to call a JS file depending on a condition, you could use a conditional statemens:<xsl:variable name="script">URL to the script or a select statement inside the variable to point to a place in the XML file for the location</xsl:variable><xsl:if test="condition"><script src="{$script}"></script></xsl:if>I don't understand the question completely. What do you mean? Hm... do you mean if the JavaScript will manipulate the XHTML output or the XSLT file it's used in? If that's the case... I don't know actually. You should make some kind of test to see that.
-
They say there are two types of validation- Errorles one and spiritual one. The way I see it rainmo offers an errorles solution. However it doesn't get into the spirit of web standarts.As scott100 mentioned already, the hr is not deprecated. Only it's presentational attributes are. Infact, I think it's better to use a hr instead of an empty div for every purpose, not only when you need a line.
-
By "clean" I mean without composing the full application for yourself. For example, XSLT could be used for transforming an RSS feed and then a server side code could execute that transformation. The other way is to use the server side script to read and transform the XML and execute it in the page. The second way is not "clean" because it relyes on heavy programming which takes lots and lots of code (not to mention CPU power).The same way, I don't know about any server side XSL-FO processors that would execute the XSL-FO file and generate a PDF file from the output but I'm completely positive that a heavy and overcrowded server side script could somehow process the whole XML after you have predefined each function of XSL-FO inside the server side script itself and execute the XSL-FO as if it's a test file with predefined by script functions.That apache extension you are talking about sounds a bit different though. And I don't get it completely. Anyway, if you could preview the XSL-FO output instead of getting error there, I don't think there should be a problem. But if the error is not in the XSLT or XSL-FO, I don't know what can you do.
-
The way I see it, you were confused by your own structured way of presentig data . The only mistakes you have is that you misplaced the achor and it's content and thus you have wrong XPath expressions everywhere.Just to clear the things up with the link first: starting an XPath expression with a forward slash("/") makes it absolute. If you are going to use an absolute value, it should look like this: <a><xsl:attribute name="href"><xsl:value-of select="/topic/contents/tag5" /></xsl:attribute><xsl:value-of select="/topic/contents/tag6" /></a> Look at your XPath expressions. Adjustings to the XML always lead to adjustments in the XSLT. Now if I have understood your methods correctly, it should be something like this: <xsl:stylesheet version="1.0"xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:template match="/"><html><body><h2>My note</h2><xsl:apply-templates/></body></html></xsl:template><xsl:template match="subject"><p><xsl:apply-templates select="tag1"/><xsl:apply-templates select="tag4"/></p></xsl:template><xsl:template match="tag1">Topic: <xsl:value-of select="."/><br/></xsl:template><xsl:template match="tag2">Title: <span style="color:#ff0000"><xsl:value-of select="."/></span><br /></xsl:template><xsl:template match="tag3"><xsl:choose><xsl:when test="tag5"><a><xsl:attribute name="href"><xsl:value-of select="tag5" /></xsl:attribute><xsl:value-of select="tag6" /></a><br/></xsl:when><xsl:otherwise><span style="color:#00f000"><xsl:value-of select="."/></span><br/></xsl:otherwise></xsl:choose></xsl:template><xsl:template match="tag4"><xsl:apply-templates select="tag2" /><xsl:apply-templates select="tag3 /></xsl:template></xsl:stylesheet> And also some small adjustments to make the XML more organized again: <tag3><tag5>C://Webdocs/java.html</tag5><tag6>content5</tag6></tag3>
-
There's no way without a server side script. As for what is the server side script or it's code... I have no idea. I haven't attempted this. I only know it's not possible via markup languages and client side ones.
-
LOL, theese are really high prisez. Hope you'll sucseed with them (though you shouldn't expect anything from me ).As for a pay function in WAP. I think it would be very difficult. Not to mention than any smart person won't buy anything from WAP. Why? There's no SSL encryption on WAP protocols. Only some "advanced" cell phones, that support XHTML sometimes have a support for SSL also.Alternative solution that you should use is to make a main site (XHTML pages) from which users would sign in and buy what they want. Then from the WAP site, they would have to login and download the thing they have paid for from a customized list of products. Unclear?Example:I go in your site and look at some good ringtone that would like to have. I create an account and I pay for it via a credit card or something on the main site. That ringtone gets inside a special section in my account. I grab my mobile phone and go into the WAP site version of your site. I login and go to the special section in which the ringtone I have bought is. I download it and the deal is over.This is certanly the best and most secure method for doing things.Yes, you could use a regular domain for a wap site. After all, a WAP site differs only with their special kind of files(WML). There are also ways with which you could have only one main page and make a server side script that would detect if the WAP or XHTML version should be used. If you don't/can't do it, you could always make something like domain.com/wap/ and domain.com that would be the XHTML site.
-
First stop: XSD is XML Schema Definition as far as I know. I presume you were mistyping XSL the second and third time (I can't say about the first)?In my personal opinion, again there's no point of using XSL-FO, scince you could process the XSLT with a server side script and transform the XHTML output into PDF then. Infact, I don't know if there's a "clean" way with which you could execute XSL-FO as PDF. I haven't heard of such a thing, but if there is, then XSL-FO is truly the easiest way to go.Well, of course you could use data from XML inside an XSL-FO document. The idea of XSL-FO is to format an XML data after all. If XSL-FO alone can't do it, then a combination of XSLT and XSL-FO surely can.
-
If it wasn't for a portfolio, I would have said it sucks in comparrison with the previous ones .Well, I think it might be good if the links were avaiable hirizontally or placed below the search, instead of vertically on the right top, but maybe it's just me.
-
I think the best way you may present things is by allowing the users to upload things via a main web site, which from then on would also be available to WAP. Thats the most sure way that no one will sue you, scince your users are responsible for themselves. Of course, as a good admin, you would be expected to delete each image and ringtone for which someone says it's illegal.This was all if you wanted the stuff to be avaiable for free, but you want it paid... hm.. well, yeah. The only way for things to be legal is to contact the producing company(es) and ask for copyrights. They would of course want percentage or something. I don't know. You'll figure it out with them. The key thing here is not to contact each movie/music producer. Instead, you would have to look for the producing comapny's president, because he owns everyone else. So, having a contract with the director of the Hulk is not the thing. Instead you would need to contact the director of... what company produced the Hulk again?
-
I love the way your XSLT looks like. It almost makes me feel as all of my XSLT experiments were useless . In fact, that's the first time I see a working usage of the <xsl:apply-templates> where it comes as a really useful feature.Your XML could use a bit of recategorization though. You could group things that belong at one place. For example: <tag4><tag2>title1: </tag2><contents><tag3>content1</tag3><tag3>content2</tag3><tag3>content3</tag3><tag3>content4</desc><tag3>content5</tag3></contents></tag4><tag4><tag2>title2:</tag2><contents><tag3>content1</tag3><tag3>content2</tag3></contents></tag4> In this case, tag4 servs as a grouping for everything belongs to the particular title and contents and the contents element combines... well... yeah... all contents.Also I hope this is not the final version of the XML file you intent to use. Names such as "tag*" are horrible. Think of something with a meaning.--------------------------Anyway, let's get back to the problem. There are two ways of adding attributes in XSLT (which is practically what you need). I have described theese methods in detail here.
-
Yes. That's the route of a server side scripting which basically allows you to do everything you otherwise would be unabled to do (thats how I usually define it). You can use server side includes, that let you write the full menu inside one file and put the content of that file directly in the main file.If you want to build the site on the client side instead, there are two other ways though: a vast usage of XML and XSLT, which on a later stage you might want to execute with a server side code (cause eventually, you WILL turn to server side scripting), or a single JavaScript that writes the code for the menu. Or a third (the best for starters in the client side ways in my opinion) is a combination of theese two: write the menu in XML and XSLT and use JavaScript in each XHTML to visualize the transformation within the XHTML file.There's also the third way of frames and iframes, but due to explainable reasons, everyone is avoiding them.Hope this will give you some ideas of what you can do. As you can see from my signature and profile summary, I have chosen the path of XSLT (I don't mean XPath ) .
-
Similarly to the code above, replace <td class="data"><xsl:value-of select="CPhone"/></td> With <td class="data"> <ul> <xsl:for-each select="CPhone"> <li><xsl:value-of select="current()" /></li> </xsl:for-each> </ul> </td> It should show the desired output.
-
XML is multiplatform way for carrying data. It can't compete with SQL and never had this purpose.If you have a catalogue, you'll sure save it within a SQL database scince it will expand rapidly.But what about simpler stuff such as interface data for example? Why would you need to carry your menus inside SQL database? No, you won't. You would carry them inside server side includes, right? Well, imagine that you would like to have a different XHTML or perhaps even a WAP site. What would you do? Use server side script that will choose appropriate other server side script that will do the stuff? And what if you change your host or change from PHP to ASP or the opposite? Remake the whole site? No way. You can have different XSLT stylesheets for each kind of platform and a single server side script that would execute the appropriate one. The thing will work despite of the server side script change and if you move, you would only need to change the script that chooses and executes the XSLT. Everything else (visual) will be intact. XML carryes the data which is transformed with the different XSLTs, so there's no need of server side includes or carrying the data over several server side pages.