Austin Tashis

+ Follow
since May 23, 2003
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Austin Tashis

Just calling that function from inside a p element won't do the trick. You need to do something with the return value, like document.write() it into the page or, better yet, wait until the document is loaded and set the innerHTML property of the intended document element to the return value.

However, I do agree with Eric. This should be done on the server. If you're storing the text in a database you should be processing it first anyway to prevent SQL injection.
If you put an iframe in a hidden element, you should be able to load a document into it with or by setting its src attribute, and that document can use parent.location=[redirect url] to open your new URL. Since you should know how long a session lasts, you can use setTimeout() to delay checking until the session has expired. Otherwise, loading the hidden page will extend the sesion.
Open it in a new window, using from an existing window, specifying the features you want it to have.
Unless you're talking about frames, there is no parent/child relationship here. A window opened by a method can access the window that opened it as window.opener, and the window that opened the new window can access the new window as the object returned by the method.

K West wrote:Is pointing to files on FTP any diffrent from pointing to files on Web server?

Yes. FTP is a different protocol, and different browsers and operating systems use different "helper" apps for different protocols. Usually this is a user-configurable setting, so you really have no way of knowing, let alone controlling, what will happen when a user clicks an ftp link.
Even untyped buttons cause forms to submit in Firefox. Always return false.

Why are there two tags?
The quickest way to validate a form is to iterate the elements collection and use a switch statement to choose validation criteria by name, id, class, tagName, type or whatever, depending on how specific your validation needs to get.
Unfortunately, even if you buy the Mac version of Office, Windows users still manage to find ways of making things incompatible. Lately I've been getting a lot of documents with other documents "embedded" in them, which can't be opened even if you have the application that should open it. Also, tables in Word documents saved in the proprietary Microsoft XML format (as opposed to the proprietary Microsoft binary format) don't display correctly.

Some other apps that you might need as a Mac User in a Windows World are OmniGraffle, which reads and writes Visio files, and OmniPlan, which can import and export MS Project files.
15 years ago
To access elements within a specific document node, use its getElementsByTagName() method. In this case, element2.getElementsByTagName("input"). This will return a collection which you can iterate to find the element(s) you're looking for.

Personally, however, I'd prefer to use fieldset elements, which are form properties, not just document elements. Also, I'd use label tags for the text labels for the checkbox and radio elements, and associate them with those elements so the user can click either the control or the label and get the same result. I gives them a bigger target, and it's a pretty universal UI convention. Not only that, you can style fieldsets, labels and inputs such that you won't need divs and tables to achieve the layout you want, and the same form can be styled differently if it's used in different pages or with different user agents.
It should be sufficient to reload the modified context.

Tomcat checks jsp pages to see if their modified date is more recent than that of the compiled servlet and recompiles as necessary. It doesn't compare java source files to class or jar files because they aren't normally part of a webapp. There are IDEs that can do this for you.

Kiran Kb wrote:Hello all,

Whenever we modify a servlet class or what ever, we have to restart the tomcat server.
But thats not the case with jsp(s). We can add/remove do whatever, and it ll work w/o
actually restarting tomcat. Why is it with servlets? JSP also becomes a servlet internally
but it doesnt require restarting? What is the reason?


15 years ago
Yes, they are Struts form element tags. The point of having them there without the form tag, as I think I said before, is that the page can be embedded within a larger form in another page.

Imagine a big, complex form, made up of little modules, some of which are pretty useful all by themselves, so you might want to use the same code to create that module both inside the big page and all by its lonesome in a little popup window or letterbox iframe.

Wow! Reusable code! What a concept!

But in the popup window or iframe, it needs an html element and a form element, but if you embed those elements in the middle of another page's form element, guess what? It throws an error, of course.

Now, I can make (and have made) a little shell HTML file with nothing but html, head, body and form elements, and embed the guts of the module in that so it doesn't have to have its own html and form elements so it can then be embedded in the big form, but that's one more file I need to create and maintain, just because there's no way to make it simply grow those parts when it needs them.

It's not such a big deal. I can work with it. I just hate constraints that are imposed without any evident added value. Like I said, it could only throw errors when there are real, not just potential, problems. It was a design decision, and, I think, a bad one.

David Newton wrote:Whether or not there's "anything to be gained" isn't relevant: illegal JSP is illegal JSP. This has *nothing* to do with Struts, and everything to do with JSP compilation.

Yes, you can do it with plain old HTML, because HTML elements aren't custom tags, and aren't processed by the JSP compiler as anything other than string literals. They don't *do* anything.

In your original example what's in the section between the <html:form> tags? If they're not <html:...> form elements then I hardly see the point of using a Struts tag to generate the form element in the first place. If they are then what's the point of having them there without the form tag?

IMO you're trying to do too much in the JSP anyway, and it'd be easier and cleaner to maintain using some other mechanism, like JSTL templates, or some other solution.

In any case, there's not much more to be said about this--you're trying to do something JSP simply doesn't support.

15 years ago
The difference is that there's nothing to be gained from enclosing conditionals in other conditionals like that. You can get all the permutations you need without breaking any rules. But there are good reasons for wanting to exclude HTML tags (e.g. they might be illegal or redundant in certain contexts), and you can do it with with plain old HTML tags and produce perfectly valid HTML,

but Struts doesn't permit this, nor is there any way, through manipulating the available attributes, to cause it not to render its elements.

David Newton wrote:...

JSTL custom tags are custom tags, and Struts 2 custom tags are custom tags. They're processed in the same way, at the same time. You can't do this, either:It has nothing to do with being a Struts tag--do you see what I mean? Those are just JSTL tags. This is illegal JSP.

15 years ago
Other than that, eh? ;-)

I suppose it's tied to the functional difference, but I am having a hard time thinking of anything analogous to the <html:form> and <html:html> tags where they replace themselves with their corresponding html tags. One consequence is that they tend to have incredibly large chunks of JSP code, in all its many varieties, in their contexts, which becomes non-reusable, unless it's included from other files, which is probably the right way to do things anyway. I could go for smaller forms too, but I can't change that.

Considering how fussy they are about what you can wrap around them, I wish they could be as picky about what goes on between them. I'd start using them everywhere.

David Newton wrote:There's no difference between JSTL custom tags and Struts custom tags (other than their functionality, of course).

15 years ago
Sure, but the XHTML hierarchy and the JSP hierarchy are really two different things. I guess I was thinking the same would be true of Struts and JSTL tags. It's too bad there's no way to programmatically include Struts HTML elements without excluding all their descendant nodes. That's a real limitation.

David Newton wrote:The issue is that you can't arbitrarily nest tags like that--you can't do it in XML, either.

15 years ago
Not quite sure what you mean by "sequence." All tags are opened before they're closed.

The only thing here that's not quite correct, as I see it, is that the html and form tags are not being opened and closed in the same context, but the contexts they are in are logically identical. I even declared a special boolean variable to connect them.

Can it be that the error checking is so strict that it throws an error if there's even the slightest possibility that an error might occur, e.g. if something were to happen to the value of that variable, instead of waiting for an actual error to occur? That seems a little paranoid.

All the html you need is there. You can imagine any entities that might be appropriate in the context of an html form element. If it is a stand-alone page, the"ifs" will be true and it will use its own form and html elements; if it's embedded in another page, it will be inserted within the context of that page's form element.

Shailesh Narkhede wrote:</html:form> tag closing in <c:if test="${standAlone}"> tag this is not right.
tag opening & closing should be in propare sequence.
paste whole jsp here, we can figure out error.

15 years ago