Open GoogleCodeExporter opened 8 years ago
The target="_replace" method was set up to put extra data at the end of the
list (like Mail, when you press 'Load
50 more messages...' etc.)
But you still got what you wanted, which is still good.
Original comment by manhi...@gmail.com
on 24 Mar 2008 at 11:27
I have attached a fix to this issue.
The fix adds a new target attribute -- "_replaceinner" -- which augments the
still-existing "_replace" target.
If your link uses "_replaceinner" instead of "_replace", the new content will
replace
the container of the link element at that specific position in the DOM. There
is no
change to the existing "_replace" target, and it continues to append the new
content
at the end.
Existing iUI installations can use the patched code as-is without any
compatibility
issues. (It is backwards-compatible, with minimal changes.)
The attached iui.js file patches the latest iui.js trunk release, r169.
Original comment by t...@speednet.biz
on 15 Jul 2008 at 1:03
Attachments:
Oops, I attached an older attachment that contains a small error. Please use
this one.
Original comment by t...@speednet.biz
on 15 Jul 2008 at 1:06
Attachments:
I'd like to propose a different approach to this. Perhaps my need for
_replaceinner
are different, but what I was needing was to be able to place a link on a page
that,
when clicked, would replace the innerHTML of the container that hosted the link
(in
my case, a div) ... this was to supply a paging mechanism (as in, go to page 2,
page
3, etc.)
I'm attaching a diff against SVN r178 (the latest I could find as of today.)
Original comment by tsimm...@gmail.com
on 14 Aug 2008 at 9:57
Attachments:
@tsimmons:
I don't think you took the time to see what my patch does, because the desired
behavior you're describing is exactly what it does. My idea of creating
a "_replaceinner" target replaces the contents of the container element with
the new
content. It does not just replace the link.
It is perfect for paging mechanisms, especially those that may be somewhere in
the
middle of the page. Or for "More" buttons in the middle of a page.
I would strongly recommend sticking with the patch that I have already
provided,
because it is highly compatible with existing code, with NO breaking changes.
Original comment by t...@speednet.biz
on 15 Aug 2008 at 6:00
@t...@speednet.biz
I appreciate your comments, but I did try your patch originally but it did not
work
for me. This is the (simplified) structure of my page within:
<div id="one">
<a href="page2.html">Page 2</a>
<div id="two">
<p>this is some text</p>
</div>
</div>
When the link to page2.html is clicked, I want the contents of page2.html to
replace
the innerHTML of div id="one". What your patch did for me when I tested it was
insert the contents of page2.html before div id="two". My patch will replace
the
entire contents of div id="one" with the contents of page2.html, which is the
desired effect in my scenario.
I've also developed a way to handle local anchor links within the page if
anyone is
interested. It adds another target, "_scroll", so if you have a local link like:
<a href="#point1">Jump to point 1</a>
you add a target attribute of "_scroll" like this:
<a target="_scroll" href="#point1">Jump to point 1</a>
And it will jump to your local link, just like a normal local anchor link.
The diff (again, against SVN r178) is attached. Feel free to point out errors,
problems or improvements.
Original comment by tsimm...@gmail.com
on 15 Aug 2008 at 6:36
Attachments:
You are right, but alas, that is not what this problem report is about. Maybe
you
should open a new problem report that replaces ALL the content.
Here is whatr is written above:
--------
What is the expected output? What do you see instead?
I would expect the added info to be replaced where the link is (in my case
in the beginning of the list). Instead the new material is added on the
bottom of the list.
--------
So the _replaceinner patch that I submitted is in fact *exactly* what this
problem
report is for.
Maybe you can create a different problem report with a "_replaceall", because
it is
really different.
Using "_replace" replaces the LINK and APPENDS the content.
Using "_replaceinner" replaces the LINK and INSERTS the content where the link
was.
Perhaps "_replaceall" could replace the entire contents of the container with
the
fetched content.
Original comment by t...@speednet.biz
on 15 Aug 2008 at 7:06
Ah, I understand the difference now. Yeah, I agree.
In addition, I agree with your issue 99
(http://code.google.com/p/iui/issues/detail?
id=99) to improve the coding standards. I'm adding a note to it as well, to
request
spaces be changed to tabs.
Original comment by tsimm...@gmail.com
on 15 Aug 2008 at 7:18
I've created a new issue that includes the updated diff
(http://code.google.com/p/iui/issues/detail?id=104).
Cheers,
Toby
Original comment by tsimm...@gmail.com
on 15 Aug 2008 at 8:11
Awesome, thanks Toby.
-Todd
Original comment by t...@speednet.biz
on 16 Aug 2008 at 12:21
Original comment by msgilli...@gmail.com
on 6 May 2009 at 2:37
I agree that the _replaceinner gets better mileage.
I am going to try that, but extend it still, so that you can specify the parent
id in
which you want to purge all childnodes and fill it in with from the ajax call.
Why not have a tool that does it all?
Original comment by drewd...@gmail.com
on 3 Jun 2009 at 1:30
@drewdeal have you looked at issue #104?
Original comment by msgilli...@gmail.com
on 3 Jun 2009 at 1:40
Original comment by msgilli...@gmail.com
on 29 Jul 2009 at 3:09
I just ran into this exact issue, and solved it the way the original poster
did. In
my opinion, the expectation that the link would be "replaced" when using the
_replace
target is pretty reasonable. It seems very surprising to append to the end of
whatever list you happen to be in if the link is not at the end of that list.
The
nice thing about the poster's change is that only one concept is needed -
existing
iUI users have the "show more" at the end of lists they want to extend, and
that will
continue to work with the change shown. No need for _replaceinner.
Original comment by john....@gmail.com
on 3 Oct 2009 at 7:53
@john.pvd: I agree with you in theory, but the problem is that the designers
of
iUI, as well as many other people, do not agree with us. You can't suddenly
make
iUI fail to operate on all the other existing sites either. That's the nature
of
software development. The goal is to add functionality, while not breaking all
the
existing functionality. _replaceinner accomplishes that goal: adds what you
and I
believe is the right functionality, while not changing or breaking existing
functionality.
Besides, there are times when you would WANT to append to the end of the
container,
so I would not want to lose the current functionality. I suppose _replace
could
become _append, and then _replace could be changed to the new functionality,
which
would be great syntactically, but then we're back to the problem of breaking
people's web sites. The bottom line is that adding a _replaceinner tag is a
very
small concession to make in order to add the desired functionality.
Original comment by t...@speednet.biz
on 3 Oct 2009 at 2:42
i like the idea of comment 12:
i need more control over the replacement. i like to specify an element by id
which is replaced by the result.
example:
<div id="sub_item_123">
<div class="linkClass">
<a href="..." target="_replace_to_sub_item_123">
</div>
</div>
Original comment by nietz...@gmail.com
on 6 Oct 2009 at 5:13
pls. make the css styling more independent.
i would like to have a <a class="blueButton" target"_replace">yyy</a> but this
not works because of the
styling of ALL because of this css selector:
a[target="_replace"]
this should be more
body > ul > li > a[target="_replace"]
so i can style my replace items better!
Original comment by nietz...@gmail.com
on 21 Dec 2009 at 3:33
Original comment by msgilli...@gmail.com
on 25 Sep 2011 at 11:40
a [target = "_replace"] does not work with the extension: JIT - Just In Time
Loader JavaScript ( jti-loader.js )
Original comment by rodol...@larochelle.tv
on 30 Jan 2012 at 6:52
Original issue reported on code.google.com by
alvin.li...@gmail.com
on 22 Mar 2008 at 8:17