search

olbers / iui

Automatically exported from code.google.com/p/iui
MIT License
0 stars 0 forks source link

target="_replace" only adds new material to end of list #74

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. A simple list with <li><a href="more.html" target="_replace"></a></li>
in the beginning of the lis

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.

What version of the product are you using? On what operating system?
iUI 0.13 (on Mac 10.4 + Safari and iPhone 1.1.4)

Please provide any additional information below.
If have changed the replaceElementWithSource function so it works like i
want it to. It seems to work just fine if you replace:

    page.removeChild(parent);

    while (frag.firstChild)
    page.appendChild(frag.firstChild);

with

    while (frag.firstChild)
    page.insertBefore(frag.firstChild, parent);

    page.removeChild(parent);

Original issue reported on code.google.com by alvin.li...@gmail.com on 22 Mar 2008 at 8:17

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
@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

GoogleCodeExporter commented 9 years ago 
@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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
Awesome, thanks Toby.

-Todd

Original comment by t...@speednet.biz on 16 Aug 2008 at 12:21

GoogleCodeExporter commented 9 years ago

Original comment by msgilli...@gmail.com on 6 May 2009 at 2:37

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
@drewdeal have you looked at issue #104?

Original comment by msgilli...@gmail.com on 3 Jun 2009 at 1:40

GoogleCodeExporter commented 9 years ago

Original comment by msgilli...@gmail.com on 29 Jul 2009 at 3:09

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
@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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago

Original comment by msgilli...@gmail.com on 25 Sep 2011 at 11:40

GoogleCodeExporter commented 9 years ago 
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